Repository navigation
Conversation
|
@bors try |
This comment has been minimized.
This comment has been minimized.
… r=<try> remove remaining rustc_allowed_through_unstable_modules
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
@craterbot cancel See #157814 |
|
🗑️ Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
Footnotes
|
|
Older versions of rand had a So yeah we won't be able to remove these any time soon. We could possibly remove just some of them but that doesn't seem worth it. |
|
(There was a comment here that got removed apparently. Very confusing for everyone who's following along via email notifications. Please prefer editing comments over just removing them.) |
…, 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?
Let's see if we can actually fully undo this accidental stabilization. Would be nice to be able to get rid of this hack in the compiler.