-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Move numeric consts to associated consts step1 #68325
Move numeric consts to associated consts step1 #68325
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
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.
Seeing new name collisions is somewhat concerning. Could you dig into the situation in which it's happening and how common that might be in downstream code?
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
e0e3d23
to
bd51e02
Compare
@dtolnay Adding an associated constant directly on a type which implements a trait that has an associated constant with the same name (in scope) silently makes So for this PR/RFC that means anyone implementing traits on the primitive numeric types that have constants with the same names as the ones we add will now get our new values unless they properly wrote I have not done any research into how common that might be downstream. I have no idea how I would do that except for a crater run? I hope/assume it would not be a common problem. Because even if some people have defined traits with these constants on the primitive types they are very likely the same type and the same value, it would not make sense to add these constants with different values really. And if they do have different types (like the errors I had to fix in this PR) then they will at least get a compilation error and not silently new values. The exact same thing happens if you add a function to a type that has a function with the same name defined in a trait. Neither of these can be considered breaking(?!) because that would mean you could never add constants or functions to any type, because you risk overriding similar items on traits implemented by that type. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Could someone help me fix/understand the broken |
0880ef2
to
b9831b7
Compare
Fixed. |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
9f2ff22
to
1ef705d
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
1ef705d
to
8c865e2
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
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.
The potential breakage is indeed not very nice. I'm pretty sure this is covered by RFC 1105 API Evolution and thus allowed. We should still take care, run crater and decide in the team. We'll do that once PR is green.
☀️ Try build successful - checks-azure |
Seems to pass. So do we want a crater run on this before merging? |
@craterbot check |
👌 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 |
@Mark-Simulacrum I think crater has become stuck, its percentage of completion hasn't updated all day. |
Yeah, it does that unfortunately. Cc @pietroalbini |
🎉 Experiment
|
Sounds pretty optimal to me :) Merge? |
Yep, that sounds optimal indeed. Adding inherent items is considered a minor change by RFC 1105. The particular items here are unlikely to be added by user code and even more unlikely to be added with a different meaning. I was thinking this might clash with With all that, I think the teams approval is not necessary in this case. @bors r+ |
📌 Commit 61fecfb has been approved by |
⌛ Testing commit 61fecfb with merge 2315451ad6ec1c90d93edf658ead2eaf7295cd08... |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit 61fecfb has been approved by |
…-step1, r=LukasKalbertodt Move numeric consts to associated consts step1 A subset of #67913. Implements the first step of RFC rust-lang/rfcs#2700 This PR adds the new constants as unstable constants and defines the old ones in terms of the new ones. Then fix a tiny bit of code that started having naming collisions because of the new assoc consts. Removed a test that did not seem relevant any longer. Since doing just `u8::MIN` should now indeed be valid.
Today I learned: do not edit your comment with the |
☀️ Test successful - checks-azure |
Stabilize assoc_int_consts associated int/float constants The next step in RFC rust-lang/rfcs#2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt
A subset of #67913. Implements the first step of RFC rust-lang/rfcs#2700
This PR adds the new constants as unstable constants and defines the old ones in terms of the new ones. Then fix a tiny bit of code that started having naming collisions because of the new assoc consts.
Removed a test that did not seem relevant any longer. Since doing just
u8::MIN
should now indeed be valid.