-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Allow unstable items to be re-exported unstably without requiring the feature be enabled #97301
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) soon. Please see the contribution instructions for more information. |
don't trust myself to review anything loosening our stability checks |
This also needs a test. |
When I was playing around with the test, I noticed that I could get master to pass a version of the test that looks like it should probably fail. I pushed that version of the test here master...semicoleon:reexport-feature-ignored I think we're just not checking the stability attributes on re-exports at all. So if you enable the feature the actual resolved item requires, any I'm not sure that's particularly relevant to this PR, or whether it's really worth worrying about, but I figured I'd mention it |
This comment has been minimized.
This comment has been minimized.
I went ahead and implemented a check for "public" visibility since the test failures were all on non-public |
That last test failure is a re-export, so we might need to change that test if this version of the implementation is what we want to go with |
This comment has been minimized.
This comment has been minimized.
Yeah, that's probably better, at least for a start. |
This comment has been minimized.
This comment has been minimized.
@rustbot label -S-waiting-on-author +S-waiting-on-review |
LGTM, could you also squash commits after addressing the remaining comments? |
95edcb0
to
d03c411
Compare
… feature be enabled
d667a42
to
f3d93b6
Compare
@rustbot ready |
@bors r+ |
📌 Commit f3d93b6 has been approved by |
…rochenkov Allow unstable items to be re-exported unstably without requiring the feature be enabled Closes rust-lang#94972 The diagnostic may need some work still, and I haven't added a test yet
Rollup of 5 pull requests Successful merges: - rust-lang#97058 (Various refactors to the incr comp workproduct handling) - rust-lang#97301 (Allow unstable items to be re-exported unstably without requiring the feature be enabled) - rust-lang#97738 (Fix ICEs from zsts within unsized types with non-zero offsets) - rust-lang#97771 (Remove SIGIO reference on Haiku) - rust-lang#97808 (Add some unstable target features for the wasm target codegen) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 5 pull requests Successful merges: - rust-lang#97058 (Various refactors to the incr comp workproduct handling) - rust-lang#97301 (Allow unstable items to be re-exported unstably without requiring the feature be enabled) - rust-lang#97738 (Fix ICEs from zsts within unsized types with non-zero offsets) - rust-lang#97771 (Remove SIGIO reference on Haiku) - rust-lang#97808 (Add some unstable target features for the wasm target codegen) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This seems to be the likely cause of a subtle bug, but more investigation is definitely needed: #114838. |
Ah: this patch also kicks in when |
I don't believe so, no |
The problem is that it kicks in for every unstable reexport -- whether it has an explicit Maybe it should be gated on "the item is unstable and the crate explicitly enabled |
For the purpose of fixing #94972, I think it would be enough if |
Or that, yes. (Then in std it wouldn't kick in when |
Closes #94972
The diagnostic may need some work still, and I haven't added a test yet