-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 9 pull requests #120766
Closed
Closed
Rollup of 9 pull requests #120766
Conversation
This file contains 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
It avoids a lot of repetition.
…rors resolve: Unload speculatively resolved crates before freezing cstore Name resolution sometimes loads additional crates to improve diagnostics (e.g. suggest imports). Not all of these diagnostics result in errors, sometimes they are just warnings, like in rust-lang#117772. If additional crates loaded speculatively stay and gets listed by things like `query crates` then they may produce further errors like duplicated lang items, because lang items from speculatively loaded crates are as good as from non-speculatively loaded crates. They can probably do things like adding unintended impls from speculatively loaded crates to method resolution as well. The extra crates will also get into the crate's metadata as legitimate dependencies. In this PR I remove the speculative crates from cstore when name resolution is finished and cstore is frozen. This is better than e.g. filtering away speculative crates in `query crates` because things like `DefId`s referring to these crates and leaking to later compilation stages can produce ICEs much easier, allowing to detect them. The unloading could potentially be skipped if any errors were reported (to allow using `DefId`s from speculatively loaded crates for recovery), but I didn't do it in this PR because I haven't seen such cases of recovery. We can reconsider later if any relevant ICEs are reported. Unblocks rust-lang#117772.
…oli-obk Make it so that async-fn-in-trait is compatible with a concrete future in implementation There's no technical reason why an AFIT like `async fn foo()` cannot be satisfied with an implementation signature like `fn foo() -> Pin<Box<dyn Future<Output = ()> + 'static>>`. We rejected this previously because we were uncertain about how AFITs worked with refinement, but I don't believe this needs to be a restriction any longer. r? oli-obk
…rrors hir: Make sure all `HirId`s have corresponding HIR `Node`s And then remove `tcx.opt_hir_node(hir_id)` in favor of `tcx.hir_node(hir_id)`.
match lowering: consistently lower bindings deepest-first Currently when lowering match expressions to MIR, we do a funny little dance with the order of bindings. I attempt to explain it in the third commit: we handle refutable (i.e. needing a test) patterns differently than irrefutable ones. This leads to inconsistencies, as reported in rust-lang#120210. The reason we need a dance at all is for situations like: ```rust fn foo1(x: NonCopyStruct) { let y @ NonCopyStruct { copy_field: z } = x; // the above should turn into let z = x.copy_field; let y = x; } ``` Here the `y ``````@``````` binding will move out of `x`, so we need to copy the field first. I believe that the inconsistency came about when we fixed rust-lang#69971, and didn't notice that the fix didn't extend to refutable patterns. My guess then is that ordering bindings by "deepest-first, otherwise source order" is a sound choice. This PR implements that (at least I hope, match lowering is hard to follow 🥲). Fixes rust-lang#120210 r? ``````@oli-obk`````` since you merged the original fix to rust-lang#69971 cc ``````@matthewjasper``````
…al-link, r=notriddle [rustdoc] Correctly generate path for non-local items in source code pages While browsing some crates using the "jump to def" feature, I realized that a lot of items didn't have a link generated. The reason is because we only cache foreign items if they appear in the documented API. This means that for the others, we need to infer them. r? ``@notriddle``
GVN: also turn moves into copies with projections Fixes rust-lang#120613
…ompiler-errors exhaustiveness: Prefer "`0..MAX` not covered" to "`_` not covered" There was an exception when reporting integer ranges as missing, it's been there for as long as I can remember. This PR removes it. I think it's nicer to report "`0..MAX` not covered" than "`_` not covered". This also makes it consistent with enums, where we report individual enum variants in this case (as showcased in the rest of the `empty-match.rs` test). r? `@estebank`
…, r=compiler-errors Add `SubdiagnosticMessageOp` as a trait alias. It avoids a lot of repetition. r? matthewjasper
…r-errors improve pretty printing for associated items in trait objects * Don't print a binder in front of associated items, because it's not valid syntax. * e.g. print `dyn for<'a> Trait<'a, Assoc = &'a u8>` instead of `dyn for<'a> Trait<'a, for<'a> Assoc = &'a u8>`. * Don't print associated items that are implied by a supertrait bound. * e.g. if we have `trait Sub: Super<Assoc = u8> {}`, then just print `dyn Sub` instead of `dyn Sub<Assoc = u8>`. I've added the test in the first commit, so you can see the diff of the compiler output in the second commit.
rustbot
added
A-translation
Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
rollup
A PR which is a rollup
labels
Feb 8, 2024
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Feb 8, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 8, 2024
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#119592 (resolve: Unload speculatively resolved crates before freezing cstore) - rust-lang#120103 (Make it so that async-fn-in-trait is compatible with a concrete future in implementation) - rust-lang#120206 (hir: Make sure all `HirId`s have corresponding HIR `Node`s) - rust-lang#120214 (match lowering: consistently lower bindings deepest-first) - rust-lang#120596 ([rustdoc] Correctly generate path for non-local items in source code pages) - rust-lang#120688 (GVN: also turn moves into copies with projections) - rust-lang#120727 (exhaustiveness: Prefer "`0..MAX` not covered" to "`_` not covered") - rust-lang#120734 (Add `SubdiagnosticMessageOp` as a trait alias.) - rust-lang#120739 (improve pretty printing for associated items in trait objects) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Feb 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-translation
Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
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.
Successful merges:
HirId
s have corresponding HIRNode
s #120206 (hir: Make sure allHirId
s have corresponding HIRNode
s)0..MAX
not covered" to "_
not covered" #120727 (exhaustiveness: Prefer "0..MAX
not covered" to "_
not covered")SubdiagnosticMessageOp
as a trait alias. #120734 (AddSubdiagnosticMessageOp
as a trait alias.)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup