-
Notifications
You must be signed in to change notification settings - Fork 512
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
items.static.const
conflicts with actual behavior in stable Rust
#1724
Comments
It appears this behavior is new as of Rust 1.83, and is the case when there's no interior mutability in the |
I believe this has already been resolved by #1610. |
Ah you are absolutely right, my bad! I was under the mistaken impression that the deployed reference matches the state of the repo. Btw, there seem to be two new (to me, at least) SemVer hazards here that I don't believe are mentioned in the cargo SemVer reference:
In both cases, assignments of the pub static to a downstream const will break, if my reasoning is accurate. If you think this is worth opening a cargo reference issue for, I'd be happy to open one. |
It follows the Rust release process. Master goes to https://doc.rust-lang.org/nightly/reference/ every two weeks, then it goes to https://doc.rust-lang.org/beta/reference/ after 6 weeks, then https://doc.rust-lang.org/stable/reference/ after another 6 weeks.
Yea, those do seem like things to be cautious of. Feel free to open a new issue at the cargo repo. Thanks! |
Thank you for your patience and guidance, I appreciate it! |
items.static.const
says:Yet the following works fine: playground
This may have changed as a result of recent changes related to Rust-for-Linux such as the stabilization of
const_refs_to_static
: rust-lang/rust#119618Depending on what the new rule is, there may also be a SemVer hazard here. For example, if the new rule is "consts may only refer to statics without interior mutability" then newly adding interior mutability to a pub static would appear to be a major breaking change. If so, we should consider updating the cargo SemVer reference as well.
The text was updated successfully, but these errors were encountered: