Rustc pull update #2614
Merged
Rustc pull update #2614
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to 5270b84. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
compiler: Hint at multiple crate versions if trait impl is for wrong ADT
If a user does e.g.
impl From<Bar> for foo::Foo
and get a compilation error about that `From<Bar>` is not implemented for `Foo`, check if multiple versions of the crate with `Foo` is present in the dependency graph. If so, give a hint about it.
Note that a test is added as a separate commit so it is easy to see what effect the fix has on the emitted error message.
This can be seen as a continuation of rust-lang/rust#124944.
I think this closes RUST-71693 but I haven't checked since it lacks a minimal reproducer. If this gets merged I'll ask that reporter if this fix works for them.
## Real world example
I encountered this case in the wild and didn't realize I had multiple versions of a crate in my dependency graph. So I was a bit confused at first. For reference, here is what that looked like.
<details>
<summary>Click to expand</summary>
### Before fix
```
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:5
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:48
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `auto-merge-dependabot-pull-requests-webhook` (bin "auto-merge-dependabot-pull-requests-webhook") due to 2 previous errors
```
### After fix
```
Compiling auto-merge-dependabot-pull-requests-webhook v0.1.0 (/home/martin/src/auto-merge-dependabot-prs/rust-webhook)
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:5
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
help: item with same name found
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_runtime-0.13.0/src/diagnostic.rs:43:1
|
43 | pub struct Diagnostic {
| ^^^^^^^^^^^^^^^^^^^^^
= note: perhaps two different versions of crate `lambda_runtime` are being used?
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:48
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
help: item with same name found
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_runtime-0.13.0/src/diagnostic.rs:43:1
|
43 | pub struct Diagnostic {
| ^^^^^^^^^^^^^^^^^^^^^
= note: perhaps two different versions of crate `lambda_runtime` are being used?
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `auto-merge-dependabot-pull-requests-webhook` (bin "auto-merge-dependabot-pull-requests-webhook") due to 2 previous errors
```
</details>
try-job: dist-various-1
try-job: aarch64-msvc-1
…_expansion, r=GuillaumeGomez [rustdoc] Cleanup "highlight::end_expansion" ~Looks like a ~5% improvement on the highlight benchmark. Obviously, highlighting is only a small part of rustdoc's runtime, so improvement won't be as large on rustc-perf (if there's even an improvement), but holding fingers for a nice gain.~ Perf seems neutral, but IMHO this is a nice small cleanup regardless. r? `@GuillaumeGomez` (& perf run please!)
Rollup of 3 pull requests Successful merges: - rust-lang/rust#146027 (support link modifier `as-needed` for raw-dylib-elf) - rust-lang/rust#146874 (compiler: Hint at multiple crate versions if trait impl is for wrong ADT ) - rust-lang/rust#147237 ([rustdoc] Cleanup "highlight::end_expansion") r? `@ghost` `@rustbot` modify labels: rollup
GVN: Use a VnIndex in Address projection. The current implementation of address projections is inconsistent. Indexing semantically relies on the index' value, but the implementation uses the index' place. This PR fixes that by using `ProjectionElem<VnIndex, Ty<'tcx>>` instead of the raw `PlaceElem<'tcx>`. This is a more principled fix than the workaround in rust-lang/rust#145030.
Refactor remove_noop_landing_pads in two loops. The point is to avoid clearing the CFG cache as often. r? `@ghost` for perf
Prevent downstream `impl DerefMut for Pin<LocalType>` The safety requirements for [`PinCoerceUnsized`](https://doc.rust-lang.org/stable/std/pin/trait.PinCoerceUnsized.html) are essentially that the type does not have a malicious `Deref` or `DerefMut` impl. However, the `Pin` type is fundamental, so the end-user can provide their own implementation of `DerefMut` for `Pin<&SomeLocalType>`, so it's possible for `Pin` to have a malicious `DerefMut` impl. This unsoundness is known as rust-lang/rust#85099. Unfortunately, this means that the implementation of `PinCoerceUnsized` for `Pin` is currently unsound. To fix that, modify the impl so that it becomes impossible for downstream crates to provide their own implementation of `DerefMut` for `Pin` by abusing a hidden struct that is not fundamental. This PR is a breaking change, but it fixes rust-lang/rust#85099. The PR supersedes rust-lang/rust#144896. r? lcnr
`DepNodeColor` tweaks A follow-up to rust-lang/rust#147293, where I attempted and mostly failed to make things faster again, but I found a few cleanups worth doing. r? `@saethlin`
add multi-arch asm! label operand test Added this since the other label operand tests are only for x86
Move more code to `RawVec::finish_grow` This move a branch and more code into the cold method `finish_grow`, which means that less code is inlined at each `try_reserve` site. Additionally, this reduces the amount of parameters, so they can all be passed by registers.
…ono1, r=saethlin Fix normalization overflow ICEs in monomorphization Fixes rust-lang/rust#92004 Fixes rust-lang/rust#92470 Fixes rust-lang/rust#95134 Fixes rust-lang/rust#105275 Fixes rust-lang/rust#105937 Fixes rust-lang/rust#117696-2 Fixes rust-lang/rust#118590 Fixes rust-lang/rust#122823 Fixes rust-lang/rust#131342 Fixes rust-lang/rust#139659 ## Analysis: The causes of these issues are similar. They contain generic recursive functions that can be instantiated with different args infinitely at monomorphization stage. Ideally this should be caught by the [`check_recursion_limit`](https://github.com/rust-lang/rust/blob/c0bb3b98bb7aac24a37635e5d36d961e0b14f435/compiler/rustc_monomorphize/src/collector.rs#L468) function. The reality is that normalization can reach recursion limit earlier than monomorphization's check because they calculate depths in different ways. Since normalization is called everywhere, ICEs appear in different locations. ## Fix: If we abort on overflow with `TypingMode::PostAnalysis` in the trait solver, it would also catch these errors. The main challenge is providing good diagnostics for them. So it's quite natural to put the check right before these normalization happening. I first tried to check the whole MIR body's normalization and `references_error`. (As elaborate_drop handles normalization failure by [returning `ty::Error`](https://github.com/rust-lang/rust/blob/c0bb3b98bb7aac24a37635e5d36d961e0b14f435/compiler/rustc_mir_transform/src/elaborate_drop.rs#L514-L519).) It turns out that checking all `Local`s seems sufficient. These types are gonna be normalized anyway. So with cache, these checks shouldn't be expensive. This fixes these ICEs for both the next and old solver, though I'm not sure the change I made to the old solver is proper. Its overflow handling looks convoluted thus I didn't try to fix it more "upstream".
only call polymorphic array iter drop machinery when the type requires it I saw a bunch of dead, empty `<[core::mem::maybe_uninit::MaybeUninit<T>; N] as core::array::iter::iter_inner::PartialDrop>::partial_drop` functions when compiling with more than 1 CGU. Let's see if we can help optimizations to eliminate stuff earlier. r? ghost
Remove boxes from ast list elements Less indirection should be better perf.
`TaskDeps` improvements Some cleanups and minor perf improvements relating to `TaskDeps`. r? `@saethlin`
mismatched_lifetime_syntax lint refactors and optimizations I found several opportunities to return early so I'm hoping those will have a perf improvement. Otherwise, it's various refactors for simplicity.
Refactor move analysis subpath representation Follow up to rust-lang/rust#147055 This PR does two things: 1. Document/validate move analysis's assumptions about `Subslice` projections 2. Decouple move paths from `ProjectionElem`, using a new enum `MoveSubPath` instead - This would be needed eventually when `ProjectionElem::Deref` is removed I wanted to do even more abstraction, making `MovePathLookup::find` return an iterator to remove the special handling of subslices in borrowck, but that regressed diagnostics and just wasn't worth the complexity.
Parse `const unsafe trait` properly Previously, this was greedily stolen by the `fn` parsing logic. r? project-const-traits
MirPatch: Simplify new_local. Small simplification.
comments for deduce_param_attrs Cc `@saethlin` since IIRC you experimented with codegen doing post-mono MIR ops? That seems to be in conflict with this pass. Cc `@tmiasko` r? `@scottmcm`
Rollup of 4 pull requests Successful merges: - rust-lang/rust#147575 (Refactor move analysis subpath representation) - rust-lang/rust#147864 (Parse `const unsafe trait` properly) - rust-lang/rust#147868 (MirPatch: Simplify new_local.) - rust-lang/rust#147873 (comments for deduce_param_attrs) r? `@ghost` `@rustbot` modify labels: rollup
use minicore for more tests r? `@jieyouxu` Unfortunately this doesn't work for all tests; minicore sometimes fails to build with errors like ``` rustc-LLVM ERROR: ILP32E cannot be used with the D ISA extension ``` and ``` error: the target features paca, pacg must all be either enabled or disabled together ``` These errors are meant to be triggered in the tests, but not in minicore. It seems like all ``@compile-flags`` are forwarded to minicore. Maybe we should exclude `-Ctarget-feature` from that? Or provide some way to set flags only for the current file, not minicore?
Offload host2 r? `@oli-obk` A follow-up to my previous gpu host PR. With this, I can (in theory) run a sufficiently simple Rust function on GPUs. I tested it on AMD, where the amdgcn tartget of rustc causes issues due to Addressspace castings, which might not be valid. If I (manually) fix them, I can run the generated IR on an AMD GPU. This should conceptually also work on NVIDIA or Intel. I updated the dev-guide acordingly: https://rustc-dev-guide.rust-lang.org/offload/usage.html I am unhappy with the amount of standalone functions in my offload code, so in my second commit I bundled some of the code around two structs which are Rust versions of the LLVM/Offload structs which they represent. The structs themselves only have doc comments. Since I directly lower everything to llvm-ir I didn't saw a big value in modelling the struct member variables.
Further tighten up relaxed bounds Follow-up to rust-lang/rust#142693, rust-lang/rust#135331 and rust-lang/rust#135841. Fixes rust-lang/rust#143122. * Reject relaxed bounds `?Trait` in the bounds of trait aliases. Just like `trait Trait {}` doesn't mean `trait Trait: Sized {}` and we therefore reject `trait Trait: ?Sized {}`, `trait Trait =;` (sic!) doesn't mean `trait Trait = Sized;` (never did!) and as a logical consequence `trait Trait = ?Sized;` is meaningless and should be forbidden. * Don't permit `?Sized` in more places (e.g., supertrait bounds, trait object types) if feature `more_maybe_bounds` is enabled. That internal feature is only meant to allow the user to define & use *new* default traits (that have fewer rules to follow for now to ease experimentation). * Unconditionally check that the `Trait` in `?Trait` is a default trait. Previously, we would only perform this check in selected places which was very brittle and led to bugs slipping through. * Slightly improve diagnostics.
enzyme/autodiff is compatible with download-ci=true To my surprise autodiff just works out of the box with download-ci=true. Thanks to all the bootstrap people who over the past helped me to link properly against the sysroot LLVM, which seems to pay off here. That also helps with enabling Rust in Enzyme CI, since CCache for some reason doesn't seem to cache LLVM correctly on their runners. I verified that this works with ` ./configure --release-channel=nightly --enable-llvm-enzyme --enable-option-checking --disable-docs --enable-llvm-assertions --set llvm.download-ci-llvm=true`. However, shouldn't download-ci-llvm already be the default? Why do I still have to manually set it with this pr? I tested it afterwards with `./x.py test --stage 1 tests/codegen-llvm/autodiff` r? bootstrap closes rust-lang/rust#147535
compiletest: Move `AuxProps` out of `EarlyProps` The primary purpose of `EarlyProps` is to discover revisions, so that we can create a separate test structure for each revision. Revisions can (and do) have different auxiliaries, and up-to-date checking is already done per-revision, so it makes more sense to perform up-to-date checks based on the current revisions's auxiliaries only. r? jieyouxu
compiletest: Store the selected edition in `TestProps` While working on a larger overhaul of directive processing, I ran into difficulty with the `has_edition` local variable. Storing the selected edition in `TestProps` should make it easier to extract parts of directive processing into independent handler functions, because the `//@ edition` handler won't need access to additional mutable state outside of `TestProps`. We still automatically add the edition to `compile_flags`, because there is too much existing compiletest code relying on that behaviour. r? jieyouxu
Rollup of 4 pull requests Successful merges: - rust-lang/rust#147734 (Further tighten up relaxed bounds) - rust-lang/rust#147888 (enzyme/autodiff is compatible with download-ci=true) - rust-lang/rust#147898 (compiletest: Move `AuxProps` out of `EarlyProps`) - rust-lang/rust#147903 (compiletest: Store the selected edition in `TestProps`) r? `@ghost` `@rustbot` modify labels: rollup
Improve error message for ambiguous numeric types in closure parameters Closes rust-lang/rust#147312
fix incorrect line number when building trimmed multi-line suggestions While fixing the issue rust-lang/rust-clippy#15883 from `rust-clippy`, I tracked it down to a problem in `rustc` where line numbers were incorrect when building trimmed multi-line suggestions.
btree: some cleanup with less unsafe
Change the tidy license checker This adds a bunch of licenses to the global list of allowed licenses that are at least as permissive as some other license in the list. In addition it adds another list for licenses that are allowed to be used by tools, but not by the runtime. All permissive licenses from the exception lists are added here. This makes it clearer what actual exceptions to our permissive licensing policy are and will hopefully make it a bit easier to review future changes to the list of licenses rather than just adding whatever license is necessary to the global list of allowed licenses or to the list of exceptions.
Rollup of 4 pull requests Successful merges: - rust-lang/rust#147577 (Improve error message for ambiguous numeric types in closure parameters) - rust-lang/rust#147785 (fix incorrect line number when building trimmed multi-line suggestions) - rust-lang/rust#147814 (btree: some cleanup with less unsafe) - rust-lang/rust#147843 (Change the tidy license checker) r? `@ghost` `@rustbot` modify labels: rollup
This updates the rust-version file to 4068bafedd8ba724e332a5221c06a6fa531a30d2.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 4068bafedd8ba724e332a5221c06a6fa531a30d2 Filtered ref: da574cb Upstream diff: rust-lang/rust@4fa824b...4068baf This merge was created using https://github.com/rust-lang/josh-sync.
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.