-
Notifications
You must be signed in to change notification settings - Fork 535
items.static.const
conflicts with actual behavior in stable Rust
#1724
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: