Support unstable moves via stable in unstable items - #95956
Conversation
|
r? @cjgillot (rust-highfive has picked a reviewer for you, use r? to override) |
f078c1c to
fc7dd28
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
9727750 to
e012a80
Compare
This comment has been minimized.
This comment has been minimized.
|
This is now also a T-libs-api PR because of the |
|
Also blocked on rust-lang/stdarch#1303 @rustbot blocked |
This comment has been minimized.
This comment has been minimized.
f5cdb56 to
6c2d0b4
Compare
|
This should be ready now that rust-lang/stdarch#1303 has merged. @rustbot ready |
Fixes rust-lang#99286 PR rust-lang#95956 accidentally made these intrinsics unstable when accessed through the unstable path segment 'std::intrinsics'
Mark stabilized intrinsics with `rustc_allowed_through_unstable_modules` Fixes rust-lang#99286 PR rust-lang#95956 accidentally made these intrinsics unstable when accessed through the unstable path segment 'std::intrinsics'
Support unstable moves via stable in unstable items part of https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/moving.20items.20to.20core.20unstably and a blocker of rust-lang#90328. The libs-api team needs the ability to move an already stable item to a new location unstably, in this case for Error in core. Otherwise these changes are insta-stable making them much harder to merge. This PR attempts to solve the problem by checking the stability of path segments as well as the last item in the path itself, which is currently the only thing checked.
|
@yaahc so this PR led to a performance regression - I see that a perf run was performed (accidentally) before this was merged, but it wasn't looked at. Is there a reason that the performance difference wasn't taken into account? In either case, we should at least address the performance regression with a justification if one is warranted. The change seems to be localized to incremental compilation scenarios. It seems queries like |
only because I hadn't intended to run it in the first place, I just didn't pay attention to it.
I don't have a solid explanation for why that's happening, I don't have much experience with interpreting perf reports for the compiler. Where are you seeing that From the impl itself I'd expect that the main difference is that we hit the stability check function much more often because of: https://github.com/rust-lang/rust/pull/95956/files#diff-5f57ad10e1bdde3d046b258d390fd2ecc6f1511158aa130cebb72093da16ef29R851, but I don't know how that relates to incremental compilation at all. |
|
You can see differences in query perf on this page. You can see there that I'm also unsure, as I don't see anything that would cause encoding the dep graph more often, but I'm really not familiar enough with this code to say for sure. The regressions are sort of right on the line between being small enough to shrug off and big enough to really care about investigating. I'll leave it to you on what to do next. Feel free to reach out if you want to chat through things. |
|
I ran a Cachegrind diff. The results absolutely match up with what @rylev said about the incremental dep graph. |
Correctly handle path stability for 'use tree' items PR rust-lang#95956 started checking the stability of path segments. However, this was not applied to 'use tree' items (e.g. 'use some::path::{ItemOne, ItemTwo}') due to the way that we desugar these items in HIR lowering. This PR modifies 'use tree' lowering to preserve resolution information, which is needed by stability checking.
library: fix some stability annotations This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing rust-lang#132481. ### `core::char` / `std::char` In rust-lang#26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0. In rust-lang#49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0. By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example. ### `{core,std}::array` and `{core,std}::array::TryFromSliceError` In rust-lang#58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to rust-lang#95956 to existing yet. Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in rust-lang#60657, but then getting backported for 1.35.0 in rust-lang#60838. This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
Rollup merge of rust-lang#132482 - lukas-code:stab-attrs, r=Noratrieb library: fix some stability annotations This PR updates some stability attributes to correctly reflect when some items actually got stabilized. Found while testing rust-lang#132481. ### `core::char` / `std::char` In rust-lang#26192, the `core::char` module got "stabilized" for 1.2.0, but the `core` crate itself was still unstable until 1.6.0. In rust-lang#49698, the `std::char` module was changed to a re-export of `core::char`, making `std::char` appear as "stable since 1.2.0", even though it was already stable in 1.0.0. By marking `core::char` as stable since 1.0.0, the docs will show correct versions for both `core::char` (since 1.6.0) and `std::char` (since 1.0.0). This is also consistent with the stabilities of similar re-exported modules like `core::mem`/`std::mem` for example. ### `{core,std}::array` and `{core,std}::array::TryFromSliceError` In rust-lang#58302, the `core::array::TryFromSliceError` type got stabilized for 1.34.0, together with `TryFrom`. At that point the `core::array` module was still unstable and a `std::array` re-export didn't exist, but `core::array::TryFromSliceError` could still be named due to rust-lang#95956 to existing yet. Then, `core::array` got stabilized and `std::array` got added, first targeting 1.36.0 in rust-lang#60657, but then getting backported for 1.35.0 in rust-lang#60838. This means that `core::array` and `std::array` actually got stabilized in 1.35.0 and `core::array::TryFromSliceError` was accessible through the unstable module in 1.34.0 -- mark them as such so that the docs display the correct versions.
…, r=nnethercote,RalfJung implement FCW for `rustc_allowed_through_unstable_modules` items Back in rust-lang#95956 we changed how stability checking of paths works, by checking the stability of all segments rather than just the last item in it. This meant that several items in the (unstable) `std::intrinsics` module, which were stable and re-exported elsewhere, could not be imported on stable anymore. By doing so, this broke everyone who imported (one example) `transmute` through `std::intrinsics::transmute` rather than `std::mem::transmute`. To fix this regression, it also introduced the `rustc_allowed_through_unstable_modules` attribute, which is a hack to allow stable imports through unstable paths. We have been emitting the `deprecated` lint for this since Rust 1.86 (in rust-lang#136434). A recent [crater run](rust-lang#157082) showed that many crates still depend on this accidental stabilization: - 7859 total regressions - 5k+ in old `rand-core` versions, new fixed minor versions released 3 weeks ago (after the crater run) in rust-random/rand_core#82 (comment) - 600 from `trim-in-place`, which has a new major (but not minor) fixed version (magiclen/trim-in-place#6) - 600 from `wide`, has a fixed minor version (errors were in wide-0.7.32, fix is in 0.7.33) Note however that the number of root regressions is very low (<100); almost all regressions are in (outdated) dependencies. The deprecation warnings have gotten people to fix their own code, but they cannot know about issues in their dependencies. However, supporting this hack in the compiler significantly complicates the implementation of stability checking. Thus I'd really like to be able to get rid of this hack. That can't happen with so many regressions, but a step towards that is to start linting more aggressively on it. This PR turns the lint into an FCW. Tracking issue: rust-lang#163160 Zulip thread: [#t-lang > fcwing on rustc_allowed_through_unstable_modules imports @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/fcwing.20on.20rustc_allowed_through_unstable_modules.20imports/near/620474117) I don't know whose territory this is - adding new lints is lang's, but what library imports are valid is up to libs?
…, r=nnethercote,RalfJung implement FCW for `rustc_allowed_through_unstable_modules` items Back in rust-lang#95956 we changed how stability checking of paths works, by checking the stability of all segments rather than just the last item in it. This meant that several items in the (unstable) `std::intrinsics` module, which were stable and re-exported elsewhere, could not be imported on stable anymore. By doing so, this broke everyone who imported (one example) `transmute` through `std::intrinsics::transmute` rather than `std::mem::transmute`. To fix this regression, it also introduced the `rustc_allowed_through_unstable_modules` attribute, which is a hack to allow stable imports through unstable paths. We have been emitting the `deprecated` lint for this since Rust 1.86 (in rust-lang#136434). A recent [crater run](rust-lang#157082) showed that many crates still depend on this accidental stabilization: - 7859 total regressions - 5k+ in old `rand-core` versions, new fixed minor versions released 3 weeks ago (after the crater run) in rust-random/rand_core#82 (comment) - 600 from `trim-in-place`, which has a new major (but not minor) fixed version (magiclen/trim-in-place#6) - 600 from `wide`, has a fixed minor version (errors were in wide-0.7.32, fix is in 0.7.33) Note however that the number of root regressions is very low (<100); almost all regressions are in (outdated) dependencies. The deprecation warnings have gotten people to fix their own code, but they cannot know about issues in their dependencies. However, supporting this hack in the compiler significantly complicates the implementation of stability checking. Thus I'd really like to be able to get rid of this hack. That can't happen with so many regressions, but a step towards that is to start linting more aggressively on it. This PR turns the lint into an FCW. Tracking issue: rust-lang#163160 Zulip thread: [#t-lang > fcwing on rustc_allowed_through_unstable_modules imports @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/fcwing.20on.20rustc_allowed_through_unstable_modules.20imports/near/620474117) I don't know whose territory this is - adding new lints is lang's, but what library imports are valid is up to libs?
…, r=nnethercote,RalfJung implement FCW for `rustc_allowed_through_unstable_modules` items Back in rust-lang#95956 we changed how stability checking of paths works, by checking the stability of all segments rather than just the last item in it. This meant that several items in the (unstable) `std::intrinsics` module, which were stable and re-exported elsewhere, could not be imported on stable anymore. By doing so, this broke everyone who imported (one example) `transmute` through `std::intrinsics::transmute` rather than `std::mem::transmute`. To fix this regression, it also introduced the `rustc_allowed_through_unstable_modules` attribute, which is a hack to allow stable imports through unstable paths. We have been emitting the `deprecated` lint for this since Rust 1.86 (in rust-lang#136434). A recent [crater run](rust-lang#157082) showed that many crates still depend on this accidental stabilization: - 7859 total regressions - 5k+ in old `rand-core` versions, new fixed minor versions released 3 weeks ago (after the crater run) in rust-random/rand_core#82 (comment) - 600 from `trim-in-place`, which has a new major (but not minor) fixed version (magiclen/trim-in-place#6) - 600 from `wide`, has a fixed minor version (errors were in wide-0.7.32, fix is in 0.7.33) Note however that the number of root regressions is very low (<100); almost all regressions are in (outdated) dependencies. The deprecation warnings have gotten people to fix their own code, but they cannot know about issues in their dependencies. However, supporting this hack in the compiler significantly complicates the implementation of stability checking. Thus I'd really like to be able to get rid of this hack. That can't happen with so many regressions, but a step towards that is to start linting more aggressively on it. This PR turns the lint into an FCW. Tracking issue: rust-lang#163160 Zulip thread: [#t-lang > fcwing on rustc_allowed_through_unstable_modules imports @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/fcwing.20on.20rustc_allowed_through_unstable_modules.20imports/near/620474117) I don't know whose territory this is - adding new lints is lang's, but what library imports are valid is up to libs?
Rollup merge of #163161 - mejrs:deprecated_intrinsic_imports, r=nnethercote,RalfJung implement FCW for `rustc_allowed_through_unstable_modules` items Back in #95956 we changed how stability checking of paths works, by checking the stability of all segments rather than just the last item in it. This meant that several items in the (unstable) `std::intrinsics` module, which were stable and re-exported elsewhere, could not be imported on stable anymore. By doing so, this broke everyone who imported (one example) `transmute` through `std::intrinsics::transmute` rather than `std::mem::transmute`. To fix this regression, it also introduced the `rustc_allowed_through_unstable_modules` attribute, which is a hack to allow stable imports through unstable paths. We have been emitting the `deprecated` lint for this since Rust 1.86 (in #136434). A recent [crater run](#157082) showed that many crates still depend on this accidental stabilization: - 7859 total regressions - 5k+ in old `rand-core` versions, new fixed minor versions released 3 weeks ago (after the crater run) in rust-random/rand_core#82 (comment) - 600 from `trim-in-place`, which has a new major (but not minor) fixed version (magiclen/trim-in-place#6) - 600 from `wide`, has a fixed minor version (errors were in wide-0.7.32, fix is in 0.7.33) Note however that the number of root regressions is very low (<100); almost all regressions are in (outdated) dependencies. The deprecation warnings have gotten people to fix their own code, but they cannot know about issues in their dependencies. However, supporting this hack in the compiler significantly complicates the implementation of stability checking. Thus I'd really like to be able to get rid of this hack. That can't happen with so many regressions, but a step towards that is to start linting more aggressively on it. This PR turns the lint into an FCW. Tracking issue: #163160 Zulip thread: [#t-lang > fcwing on rustc_allowed_through_unstable_modules imports @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/fcwing.20on.20rustc_allowed_through_unstable_modules.20imports/near/620474117) I don't know whose territory this is - adding new lints is lang's, but what library imports are valid is up to libs?
part of https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/moving.20items.20to.20core.20unstably and a blocker of #90328.
The libs-api team needs the ability to move an already stable item to a new location unstably, in this case for Error in core. Otherwise these changes are insta-stable making them much harder to merge.
This PR attempts to solve the problem by checking the stability of path segments as well as the last item in the path itself, which is currently the only thing checked.