[pull] master from rust-lang:master #12
Open
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
The `Item` struct is 48 bytes and contains a `Box<ItemInner>`; `ItemInner` is 104 bytes. This is an odd arrangement. Normally you'd have one of the following. - A single large struct, which avoids the allocation for the `Box`, but can result in lots of wasted space in unused parts of a container like `Vec<Item>`, `HashSet<Item>`, etc. - Or, something like `struct Item(Box<ItemInner>)`, which requires the `Box` allocation but gives a very small Item size, which is good for containers like `Vec<Item>`. `Item`/`ItemInner` currently gets the worst of both worlds: it always requires a `Box`, but `Item` is also pretty big and so wastes space in containers. It would make sense to push it in one direction or the other. #138916 showed that the first option is a regression for rustdoc, so this commit does the second option, which improves speed and reduces memory usage.
I noticed that `PartialOrd` implementation for `bool` does not override the individual operator methods, unlike the other primitive types like `char` and integers. This commit extracts these `PartialOrd` overrides shared by the other primitive types into a macro and calls it on `bool` too.
add FCW to warn about wasm ABI transition See #122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following: - scalar arguments are fine - including 128 bit types, they get passed as two `i64` arguments in both ABIs - `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes) - all return values are fine `@bjorn3` `@alexcrichton` `@Manishearth` is that correct? I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this? IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments. Tracking issue: #138762 Transition plan blog post: rust-lang/blog.rust-lang.org#1531 try-job: dist-various-2
…, r=oli-obk,traviscross Stabilize `#![feature(precise_capturing_in_traits)]` # Precise capturing (`+ use<>` bounds) in traits - Stabilization Report Fixes #130044. ## Stabilization summary This report proposes the stabilization of `use<>` precise capturing bounds in return-position impl traits in traits (RPITITs). This completes a missing part of [RFC 3617 "Precise capturing"]. Precise capturing in traits was not ready for stabilization when the first subset was proposed for stabilization (namely, RPITs on free and inherent functions - #127672) since this feature has a slightly different implementation, and it hadn't yet been implemented or tested at the time. It is now complete, and the type system implications of this stabilization are detailed below. ## Motivation Currently, RPITITs capture all in-scope lifetimes, according to the decision made in the ["lifetime capture rules 2024" RFC](https://rust-lang.github.io/rfcs/3498-lifetime-capture-rules-2024.html#return-position-impl-trait-in-trait-rpitit). However, traits can be designed such that some lifetimes in arguments may not want to be captured. There is currently no way to express this. ## Major design decisions since the RFC No major decisions were made. This is simply an extension to the RFC that was understood as a follow-up from the original stabilization. ## What is stabilized? Users may write `+ use<'a, T>` bounds on their RPITITs. This conceptually modifies the desugaring of the RPITIT to omit the lifetimes that we would copy over from the method. For example, ```rust trait Foo { fn method<'a>(&'a self) -> impl Sized; // ... desugars to something like: type RPITIT_1<'a>: Sized; fn method_desugared<'a>(&'a self) -> Self::RPITIT_1<'a>; // ... whereas with precise capturing ... fn precise<'a>(&'a self) -> impl Sized + use<Self>; // ... desugars to something like: type RPITIT_2: Sized; fn precise_desugared<'a>(&'a self) -> Self::RPITIT_2; } ``` And thus the GAT doesn't name `'a`. In the compiler internals, it's not implemented exactly like this, but not in a way that users should expect to be able to observe. #### Limitations on what generics must be captured Currently, we require that all generics from the trait (including the `Self`) type are captured. This is because the generics from the trait are required to be *invariant* in order to do associated type normalization. And like regular precise capturing bounds, all type and const generics in scope must be captured. Thus, only the in-scope method lifetimes may be relaxed with this syntax today. ## What isn't stabilized? (a.k.a. potential future work) See section above. Relaxing the requirement to capture all type and const generics in scope may be relaxed when #130043 is implemented, however it currently interacts with some underexplored corners of the type system (e.g. unconstrained type bivariance) so I don't expect it to come soon after. ## Implementation summary This functionality is implemented analogously to the way that *opaque type* precise capturing works. Namely, we currently use *variance* to model the capturedness of lifetimes. However, since RPITITs are anonymous GATs instead of opaque types, we instead modify the type relation of GATs to consider variances for RPITITs (along with opaque types which it has done since #103491). https://github.com/rust-lang/rust/blob/30f168ef811aec63124eac677e14699baa9395bd/compiler/rustc_middle/src/ty/util.rs#L954-L976 https://github.com/rust-lang/rust/blob/30f168ef811aec63124eac677e14699baa9395bd/compiler/rustc_type_ir/src/relate.rs#L240-L244 Using variance to model capturedness is an implementation detail, and in the future it would be desirable if opaques and RPITITs simply did not include the uncaptured lifetimes in their generics. This can be changed in a forwards-compatible way, and almost certainly would not be observable by users (at least not negatively, since it may indeed fix some bugs along the way). ## Tests * Test that the lifetime isn't actually captured: `tests/ui/impl-trait/precise-capturing/rpitit.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-outlives.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-outlives-2.rs`. * Technical test for variance computation: `tests/ui/impl-trait/in-trait/variance.rs`. * Test that you must capture all trait generics: `tests/ui/impl-trait/precise-capturing/forgot-to-capture-type.rs`. * Test that you cannot capture more than what the trait specifies: `tests/ui/impl-trait/precise-capturing/rpitit-captures-more-method-lifetimes.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-impl-captures-too-much.rs`. * Undercapturing (refinement) lint: `tests/ui/impl-trait/in-trait/refine-captures.rs`. ### What other unstable features may be exposed by this feature? I don't believe that this exposes any new unstable features indirectly. ## Remaining bugs and open issues Not aware of any open issues or bugs. ## Tooling support Rustfmt: ✅ Supports formatting `+ use<>` everywhere. Clippy: ✅ No support needed, unless specific clippy lints are impl'd to care for precise capturing itself. Rustdoc: ✅ Rendering `+ use<>` precise capturing bounds is supported. Rust-analyzer: ✅ Parser support, and then lifetime support isn't needed #138128 (comment) (previous: ~~:question: There is parser support, but I am unsure of rust-analyzer's level of support for RPITITs in general.~~) ## History Tracking issue: #130044 * #131033 * #132795 * #136554
Group test diffs by stage in post-merge analysis I think that this is clearer than including the stage in the test name. To test e.g. on [this PR](#138523): ```bash $ curl https://ci-artifacts.rust-lang.org/rustc-builds/282865097d138c7f0f7a7566db5b761312dd145c/metrics-aarch64-gnu.json > metrics.json $ cargo run --manifest-path src/ci/citool/Cargo.toml postprocess-metrics metrics.json --job-name aarch64-gnu --parent d9e5539 > out.md ``` r? `@marcoieni`
linker: Fix staticlib naming for UEFI And one minor refactoring in the second commit.
Batch mark waiters as unblocked when resuming in the deadlock handler This fixes a race when resuming multiple threads to resolve query cycles. This now marks all threads as unblocked before resuming any of them. Previously if one was resumed and marked as unblocked at a time. The first thread resumed could fall asleep then Rayon would detect a second false deadlock. Later the initial deadlock handler thread would resume further threads. This also reverts the workaround added in #137731. cc `@SparrowLii` `@lqd`
…ethlin Trusty: Fix build for anonymous pipes and std::sys::process PRs #136842 (Add libstd support for Trusty targets), #137793 (Stablize anonymous pipe), and #136929 (std: move process implementations to `sys`) merged around the same time, so update Trusty to take them into account. cc `@randomPoison`
…errors Fix ui pattern_types test for big-endian platforms The newly added pattern types validity tests fail on s390x and presumably other big-endian systems, due to print of raw values with padding bytes. To fix the tests remove the raw output values in the error note by `normalize-stderr`.
…tainer, r=compiler-errors Add target maintainer information for powerpc64-unknown-linux-musl We intend to fix the outstanding issues on the target and eventually promote it to tier 2. We have the capacity to maintain this target in the future and already perform regular builds of rustc for this target. Currently, all host tools except miri build fine, but I have a patch for libffi-sys to make miri also compile fine for this target that is [pending review](tov/libffi-rs#100). While at it, add an option for the musl root for this target. I also added a kernel version requirement, which is rather arbitrarily chosen, but it matches our tier 2 powerpc64le-unknown-linux-musl target so I think it is a good fit.
Allow defining opaques in statics and consts r? oli-obk Fixes #138902
…aumeGomez rustdoc: remove useless `Symbol::is_empty` checks. There are a number of `is_empty` checks that can never fail. This commit removes them, in support of #137978. r? `@GuillaumeGomez`
Override PartialOrd methods for bool I noticed that `PartialOrd` implementation for `bool` does not override the individual operator methods, unlike the other primitive types like `char` and integers. This commit extracts these `PartialOrd` overrides shared by the other primitive types into a macro and calls it on `bool` too. CC `@scottmcm` for our recent adventures in `PartialOrd` land
There are several places in `rustc_middle` that check for an empty lifetime name. These checks appear to be totally unnecessary, because empty lifetime names aren't produced here. (Empty lifetime names *are* possible in `hir::Lifetime`. Perhaps there was some confusion between it and the `rustc_middle` types?) This commit removes the `kw::Empty` checks.
This reverts commit e3e74bc. The comment that was used to justify the change was outdated.
Rollup of 11 pull requests Successful merges: - #138128 (Stabilize `#![feature(precise_capturing_in_traits)]`) - #138834 (Group test diffs by stage in post-merge analysis) - #138867 (linker: Fix staticlib naming for UEFI) - #138874 (Batch mark waiters as unblocked when resuming in the deadlock handler) - #138875 (Trusty: Fix build for anonymous pipes and std::sys::process) - #138877 (Ignore doctests only in specified targets) - #138885 (Fix ui pattern_types test for big-endian platforms) - #138905 (Add target maintainer information for powerpc64-unknown-linux-musl) - #138911 (Allow defining opaques in statics and consts) - #138917 (rustdoc: remove useless `Symbol::is_empty` checks.) - #138945 (Override PartialOrd methods for bool) r? `@ghost` `@rustbot` modify labels: rollup
bump thorin to 0.9 to drop duped deps
Bumps `thorin`, removing duped deps.
This also changes features for hashbrown:
```
hashbrown v0.15.2
`-- indexmap v2.7.0
|-- object v0.36.7
|-- wasmparser v0.219.1
|-- wasmparser v0.223.0
`-- wit-component v0.223.0
|-- indexmap feature "default"
|-- indexmap feature "serde"
`-- indexmap feature "std"
|-- hashbrown feature "default-hasher"
| |-- object v0.36.7 (*)
| `-- wasmparser v0.223.0 (*)
|-- hashbrown feature "nightly"
| |-- rustc_data_structures v0.0.0
| `-- rustc_query_system v0.0.0
`-- hashbrown feature "serde"
`-- wasmparser feature "serde"
```
to
```
hashbrown v0.15.2
`-- indexmap v2.7.0
|-- object v0.36.7
|-- wasmparser v0.219.1
|-- wasmparser v0.223.0
`-- wit-component v0.223.0
|-- indexmap feature "default"
|-- indexmap feature "serde"
`-- indexmap feature "std"
|-- hashbrown feature "allocator-api2"
| `-- hashbrown feature "default"
|-- hashbrown feature "default" (*)
|-- hashbrown feature "default-hasher"
| |-- object v0.36.7 (*)
| `-- wasmparser v0.223.0 (*)
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "equivalent"
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "inline-more"
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "nightly"
| |-- rustc_data_structures v0.0.0
| `-- rustc_query_system v0.0.0
|-- hashbrown feature "raw-entry"
| `-- hashbrown feature "default" (*)
`-- hashbrown feature "serde"
`-- wasmparser feature "serde"
```
To be safe, as this can be perf-sensitive:
`@bors` rollup=never
…nore-packed-align, r=workingjubilee [AIX] Ignore linting on repr(C) structs with repr(packed) or repr(align(n)) This PR updates the lint added in 9b40bd7 to ignore repr(C) structs that also have repr(packed) or repr(align(n)). As these representations can be modifiers on repr(C), it is assumed that users that add these should know what they are doing, and thus the the lint should not warn on the respective structs. For example, for the time being, using repr(packed) and manually padding a repr(C) struct can be done to correctly align struct members on AIX.
Subtree sync for rustc_codegen_cranelift The main highlights this time are a Cranelift update, support for `#[target_feature]` for inline asm on arm64 and some vendor intrinsic fixes for arm64.
…acrum
Simplify expansion for format_args!().
Instead of calling `Placeholder::new()`, we can just use a struct expression directly.
Before:
```rust
Placeholder::new(…, …, …, …)
```
After:
```rust
Placeholder {
position: …,
flags: …,
width: …,
precision: …,
}
```
(I originally avoided the struct expression, because `Placeholder` had a lot of fields. But now that #136974 is merged, it only has four fields left.)
This will make the `fmt` argument to `fmt::Arguments::new_v1_formatted()` a candidate for const promotion, which is important if we ever hope to tackle #92698 (It doesn't change anything yet though, because the `args` argument to `fmt::Arguments::new_v1_formatted()` is not const-promotable.)
…ur-ozkan bootstrap: Avoid cloning `change-id` list Inspired by [recent discussion](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Collecting.20some.20Real.20Configs.20for.20testing/near/507845657) on the bootstrap `change-id` field, I took a look at the code and found this little optimization. It does not change behavior.
Properly document FakeReads
Remove attribute `#[rustc_error]` It was an ancient way to write `check-pass` tests, but now it's no longer necessary (except for the `delayed_bug_from_inside_query` flavor, which is retained).
Improve hir_pretty for struct expressions. While working on #139131 I noticed the hir pretty printer outputs an empty line between each field, and is also missing a space before the `{` and the `}`: ```rust let a = StructWithSomeFields{ field_1: 1, field_2: 2, field_3: 3, field_4: 4, field_5: 5, field_6: 6,}; let a = StructWithSomeFields{ field_1: 1, field_2: 2, ..a}; ``` This changes it to: ```rust let a = StructWithSomeFields { field_1: 1, field_2: 2, field_3: 3, field_4: 4, field_5: 5, field_6: 6 }; let a = StructWithSomeFields { field_1: 1, field_2: 2, ..a }; ```
Switch some rustc_on_unimplemented uses to diagnostic::on_unimplemented The use on the SliceIndex impl appears unreachable, there is no mention of "vector indices" in any test output and I could not get it to show up in error messages.
Rollup of 5 pull requests Successful merges: - #139044 (bootstrap: Avoid cloning `change-id` list) - #139111 (Properly document FakeReads) - #139122 (Remove attribute `#[rustc_error]`) - #139132 (Improve hir_pretty for struct expressions.) - #139141 (Switch some rustc_on_unimplemented uses to diagnostic::on_unimplemented) r? `@ghost` `@rustbot` modify labels: rollup
Uplift `clippy::invalid_null_ptr_usage` lint as `invalid_null_arguments` This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](#111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one. *For context: GitHub Search reveals that just for `slice::from_raw_parts{_mut}` [~20 invalid usages](hhttps://github.com/search?q=lang%3Arust+%2Fslice%3A%3Afrom_raw_parts%28_mut%29%3F%5C%28ptr%3A%3Anull%2F+NOT+path%3A%2F%5Eclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F&type=code) with `ptr::null` and an additional [4 invalid usages](https://github.com/search?q=lang%3Arust+%2Fslice%3A%3Afrom_raw_parts%5C%280%28%5C%29%7C+as%29%2F+NOT+path%3A%2F%5Eclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eutils%5C%2Ftinystr%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eutils%5C%2Fzerovec%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eprovider%5C%2Fcore%5C%2Fsrc%5C%2F%2F&type=code) with `0 as *const ...`-ish casts.* ----- ## `invalid_null_arguments` (deny-by-default) The `invalid_null_arguments` lint checks for invalid usage of null pointers. ### Example ```rust // Undefined behavior unsafe { std::slice::from_raw_parts(ptr::null(), 1); } ``` Produces: ``` error: calling this function with a null pointer is Undefined Behavior, even if the result of the function is unused --> $DIR/invalid_null_args.rs:21:23 | LL | let _: &[usize] = std::slice::from_raw_parts(ptr::null_mut(), 0); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^---------------^^^^ | | | null pointer originates from here | = help: for more information, visit <https://doc.rust-lang.org/std/ptr/index.html> and <https://doc.rust-lang.org/reference/behavior-considered-undefined.html> ``` ### Explanation Calling methods whose safety invariants requires non-null pointer with a null pointer is undefined behavior. ----- The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute. This PR also includes some small refactoring to avoid some ambiguities in naming, those can be done in another PR is desired. `@rustbot` label: +I-lang-nominated r? compiler
hygiene: Rewrite `apply_mark_internal` to be more understandable The previous implementation allocated new `SyntaxContext`s in the inverted order, and it was generally very hard to understand why its result matches what the `opaque` and `opaque_and_semitransparent` field docs promise. ```rust /// This context, but with all transparent and semi-transparent expansions filtered away. opaque: SyntaxContext, /// This context, but with all transparent expansions filtered away. opaque_and_semitransparent: SyntaxContext, ``` It also couldn't be easily reused for the case where the context id is pre-reserved like in #129827. The new implementation tries to follow the docs in a more straightforward way. I did the transformation in small steps, so it indeed matches the old implementation, not just the docs. So I suggest reading only the new version.
Revert "Rollup merge of #136127 - WaffleLapkin:dyn_ptr_unwrap_cast, r=compiler-errors" ...not permanently tho. Just until we can land something like #138542, which will fix the underlying perf issues (#136127 (comment)). I just don't want this to land on beta and have people rely on this behavior if it'll need some reworking for it to be implemented performantly. r? `@WaffleLapkin` or reassign -- sorry for reverting ur pr! i'm working on getting it re-landed soon :>
Prefer built-in sized impls (and only sized impls) for rigid types always
This PR changes the confirmation of `Sized` obligations to unconditionally prefer the built-in impl, even if it has nested obligations. This also changes all other built-in impls (namely, `Copy`/`Clone`/`DiscriminantKind`/`Pointee`) to *not* prefer built-in impls over param-env impls. This aligns the old solver with the behavior of the new solver.
---
In the old solver, we register many builtin candidates with the `BuiltinCandidate { has_nested: bool }` candidate kind. The precedence this candidate takes over other candidates is based on the `has_nested` field. We only prefer builtin impls over param-env candidates if `has_nested` is `false`
https://github.com/rust-lang/rust/blob/2b4694a69804f89ff9d47d1a427f72c876f7f44c/compiler/rustc_trait_selection/src/traits/select/mod.rs#L1804-L1866
Preferring param-env candidates when the builtin candidate has nested obligations *still* ends up leading to detrimental inference guidance, like:
```rust
fn hello<T>() where (T,): Sized {
let x: (_,) = Default::default();
// ^^ The `Sized` obligation on the variable infers `_ = T`.
let x: (i32,) = x;
// We error here, both a type mismatch and also b/c `T: Default` doesn't hold.
}
```
Therefore this PR adjusts the candidate precedence of `Sized` obligations by making them a distinct candidate kind and unconditionally preferring them over all other candidate kinds.
Special-casing `Sized` this way is necessary as there are a lot of traits with a `Sized` super-trait bound, so a `&'a str: From<T>` where-bound results in an elaborated `&'a str: Sized` bound. People tend to not add explicit where-clauses which overlap with builtin impls, so this tends to not be an issue for other traits.
We don't know of any tests/crates which need preference for other builtin traits. As this causes builtin impls to diverge from user-written impls we would like to minimize the affected traits. Otherwise e.g. moving impls for tuples to std by using variadic generics would be a breaking change. For other builtin impls it's also easier for the preference of builtin impls over where-bounds to result in issues.
---
There are two ways preferring builtin impls over where-bounds can be incorrect and undesirable:
- applying the builtin impl results in undesirable region constraints. E.g. if only `MyType<'static>` implements `Copy` then a goal like `(MyType<'a>,): Copy` would require `'a == 'static` so we must not prefer it over a `(MyType<'a>,): Copy` where-bound
- this is mostly not an issue for `Sized` as all `Sized` impls are builtin and don't add any region constraints not already required for the type to be well-formed
- however, even with `Sized` this is still an issue if a nested goal also gets proven via a where-bound: [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=30377da5b8a88f654884ab4ebc72f52b)
- if the builtin impl has associated types, we should not prefer it over where-bounds when normalizing that associated type. This can result in normalization adding more region constraints than just proving trait bounds. #133044
- not an issue for `Sized` as it doesn't have associated types.
r? lcnr
Fix closure recovery for missing block when return type is specified Firstly, fix the `is_array_like_block` condition to make sure we're actually recovering a mistyped *block* rather than some other delimited expression. This fixes #138748. Secondly, split out the recovery of missing braces on a closure body into a separate recovery. Right now, the suggestion `"you might have meant to write this as part of a block"` originates from `suggest_fixes_misparsed_for_loop_head`, which feels kinda brittle and coincidental since AFAICT that recovery wasn't ever really intended to fix this. We also can make this `MachineApplicable` in this case. Fixes #138748 r? `@fmease` or reassign if you're busy/don't wanna review this
Emit `unused_attributes` for `#[inline]` on exported functions I saw someone post a code sample that contained these two attributes, which immediately made me suspicious. My suspicions were confirmed when I did a small test and checked the compiler source code to confirm that in these cases, `#[inline]` is indeed ignored (because you can't exactly `LocalCopy`an unmangled symbol since that would lead to duplicate symbols, and doing a mix of an unmangled `GloballyShared` and mangled `LocalCopy` instantiation is too complicated for our current instatiation mode logic, which I don't want to change right now). So instead, emit the usual unused attribute lint with a message saying that the attribute is ignored in this position. I think this is not 100% true, since I expect LLVM `inlinehint` to still be applied to such a function, but that's not why people use this attribute, they use it for the `LocalCopy` instantiation mode, where it doesn't work. r? saethlin as the instantiation guy Procedurally, I think this should be fine to merge without any lang involvement, as this only does a very minor extension to an existing lint.
Encode synthetic by-move coroutine body with a different `DefPathData`
See the included test. In the first revision rpass1, we have an async closure `{closure#0}` which has a coroutine as a child `{closure#0}::{closure#0}`. We synthesize a by-move coroutine body, which is `{closure#0}::{closure#1}` which depends on the mir_built query, which depends on the typeck query.
In the second revision rpass2, we've replaced the coroutine-closure by a closure with two children closure. Notably, the def path of the second child closure is the same as the synthetic def id from the last revision: `{closure#0}::{closure#1}`. When type-checking this closure, we end up trying to compute its def_span, which tries to fetch it from the incremental cache; this will try to force the dependencies from the last run, which ends up forcing the mir_built query, which ends up forcing the typeck query, which ends up with a query cycle.
The problem here is that we really should never have used the same `DefPathData` for the synthetic by-move coroutine body, since it's not a closure. Changing the `DefPathData` will mean that we can see that the def ids are distinct, which means we won't try to look up the closure's def span from the incremental cache, which will properly skip replaying the node's dependencies and avoid a query cycle.
Fixes #139142
Remove mention of `exhaustive_patterns` from `never` docs
The example shows an exhaustive match:
```rust
#![feature(exhaustive_patterns)]
use std::str::FromStr;
let Ok(s) = String::from_str("hello");
```
But #119612 moved this functionality to `#![feature(min_exhaustive_patterns)` and then stabilized it.
Remove Amanieu from the libs review rotation Unfortunately I've accumulated a large backlog of PRs to review, both in rust-lang and my own repos. Until I've cleared the backlog, I will remove myself from the review rotation for rust-lang/rust.
Rollup of 6 pull requests Successful merges: - #138176 (Prefer built-in sized impls (and only sized impls) for rigid types always) - #138749 (Fix closure recovery for missing block when return type is specified) - #138842 (Emit `unused_attributes` for `#[inline]` on exported functions) - #139153 (Encode synthetic by-move coroutine body with a different `DefPathData`) - #139157 (Remove mention of `exhaustive_patterns` from `never` docs) - #139167 (Remove Amanieu from the libs review rotation) r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )