-
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
Implement proper stability check for const impl Trait
, fall back to unstable const
when undeclared
#93960
Conversation
Some changes occurred in cc @camelid |
This comment has been minimized.
This comment has been minimized.
d156433
to
d9849cc
Compare
Does this break anything that was already (potentially accidentally) stable? I thought it wasn't possible to have a |
There were a couple of methods that didn't have it, but they were intentionally stabilized as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we now remove // build-fail
from some tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And yes, // build-fail
can likely be removed from some tests.
I would prefer solution 2, but I realize it may be a larger diff or require duplication, so i'll trust your judgement on that. I don't think we'll ever remove this stability check, after all, we will keep adding new traits and possibly make more of them const. Just like we have the const fn stability checks even though const fn is stable |
True, I was thinking of the part that emits the error, which is only part of the change. I'll look into (2). |
Do you see the need for both the |
Yea they could be merged in case there is something only tested in one of them |
I need to implement a check for a const trait impl being unstable with the feature enabled, as right now it appears that the compiler doesn't take this into account with regard to unstable-in-stable checking. Aside from that, I've merged the check into the existing stability pass. |
This comment has been minimized.
This comment has been minimized.
Status update: I'm trying to figure out how to get |
You need to set |
Already did that to no avail, unfortunately. |
Note: this will only work for the libstd built with the changed compiler. The initial libstd build will still be done with a downloaded stage0 compiler, maybe that's what you're seeing? |
In that case, how can I ensure it's built myself? |
My recommendation would be to create a ui test that reproduces the issue, and then only use logging on that test. If you do want to log libcore, you just need to wait until it gets built after the compiler is built once. Logging will work there. You will still get lots of messages about disabled log levels while building stage 0 libstd and while building the compiler, but after the compiler is built, you will get logging output |
☔ The latest upstream changes (presumably #94096) made this pull request unmergeable. Please resolve the merge conflicts. |
This avoids an ambiguity (when reading) where `.level.is_stable()` is not immediately clear whether it is general stability or const stability.
Rather than deferring to const eval for checking if a trait is const, we now check up-front. This allows the error to be emitted earlier, notably at the same time as other stability checks. Also included in this commit is a change of the default const stability level to UNstable. Previously, an item that was `const` but did not explicitly state it was unstable was implicitly stable.
This alters the diagnostics a bit, as the trait method is still stable. The only thing this check does is ensure that compilation fails if a trait implementation is declared const-stable.
f24e607
to
6a45f4d
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
Alright. So after rebasing and getting |
@jhpratt |
I still plan on working on it! I've been busy with some other things and plan on picking it back up in the near future. |
I asked on Zulip if there was anyone interested in taking this PR over (no responses yet). I have other priorities in the compiler, and I know there are still some design decisions to be made for If anyone would like to take this over, please say so! If not, I'll likely close this pull request, at least for the time being. Anyone is free to use the code in this PR in a future PR (or more generally under MIT or Apache-2.0). |
Closing for the reason stated above. @rustbot label -S-waiting-on-author +S-inactive |
Implement proper stability check for const impl Trait, fall back to unstable const when undeclared Continuation of rust-lang#93960 `@jhpratt` it looks to me like the test was simply not testing for the failure you were looking for? Your checks actually do the right thing for const traits?
Doing these as one PR because it fit with the way I was writing code. I can split them into separate commits if desired, though there's not much point.
Rather than deferring to const eval for checking if a trait is const, we now check up-front. This allows the error to be emitted earlier, notably at the same time as other stability checks.
Also included in this PR is a change of the default const stability level to UNstable. Previously, an item that was
const
but did not explicitly state it was unstable was implicitly stable.r? @oli-obk
@rustbot label +A-const-fn +A-stability +C-enhancement +F-const-trait-impl +S-waiting-on-review +T-compiler -T-rustdoc