-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Add contracts for all functions in Alignment
#136578
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
base: master
Are you sure you want to change the base?
Add contracts for all functions in Alignment
#136578
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @tgross35 (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
This comment has been minimized.
This comment has been minimized.
You could also tag
in a comment / PR description. |
Could you say some more about the motivation? This feature was merged only a number of hours ago, that seems soon to start using in std. Even once it is more stable, what should and shouldn't get contracts is probably something that needs to get discussed. @rust-lang/libs any thoughts here? |
Yeah, this was only approved as a lang experiment on the lang/compiler side, no idea what the situation is libs side (which certainly should be discussed). cc @pnkfelix @nikomatsakis @celinval (lang liason and ppl who were implementing this feature compiler side) |
I'll libs nominate this for discussion (this should only be discussed after the contracts people mentioned above have replied). |
Totally worth discussion, and it would be great to get some feedback on the features that are needed to meet the libs team bar. I am especially curious to see how you think contracts and |
It would be useful to know what your plan/intention is with adding contracts here. Is it just to try them out or is annotating the standard library with contracts for downstream consumers part of the goal of contracts? |
As far as the motivation is concerned: we're working towards https://rust-lang.github.io/rust-project-goals/2025h1/std-contracts.html, and I created this (draft) PR with the hope to initiate discussion while knowing there is a lot more work to be done on our end. As I am new contributor: is there other information that I can provide or another forum that I should use rather than this PR? |
Our current goal is https://rust-lang.github.io/rust-project-goals/2025h1/std-contracts.html, though we are in early stages and it indeed is about trying out what works best. Eventually we want to enable verification of downstream consumers, but a lot more work will be required before we get there. |
d46f868
to
7288286
Compare
This comment has been minimized.
This comment has been minimized.
Are there any docs on how contracts work as they exist today? Ignoring the stability question, we need something to refer to about how to use these properly, e.g. in https://doc.rust-lang.org/nightly/unstable-book/. Also, how are contracts that get merged into r-l/rust being verified? The linked page is somewhat vague about what this means for Bringing this up on the libs zulip would be a good idea to get the ball rolling https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs. |
library/core/src/ptr/alignment.rs
Outdated
@@ -43,6 +43,8 @@ impl Alignment { | |||
#[unstable(feature = "ptr_alignment_type", issue = "102070")] | |||
#[inline] | |||
#[must_use] | |||
#[cfg_attr(not(bootstrap), contracts::requires(mem::align_of::<T>().is_power_of_two()))] |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
7288286
to
c180bd0
Compare
This comment has been minimized.
This comment has been minimized.
c180bd0
to
4322394
Compare
This comment has been minimized.
This comment has been minimized.
We discussed this in the libs meeting today. We're happy to add contracts to the standard library as an experiment, as long as this doesn't get in the way of normal standard library development. Depending on how the contracts feature evolves, we may reconsider our level of support. |
Question from ignorance on my part: how do we encode contracts? Are they in statements/terminators, or in some other communication channel? |
COMEFROM rust-lang/compiler-team#813 (comment) Based on the writeup that @celinval has provided, it looks like contracts will cause us to have new Call terminators in MIR, and that would indeed be quite an unfortunate situation for the MIR optimization pipeline. That being said, I don't think I have anything useful/actionable to say other than "yeah that sounds like it could be bad" until we have actual data to work with. The |
For sure, we'll have to be cautious about performance. I think one possibility is to remove the existing mechanism to delay enable/disable contract as late as codegen. I kinda wish there was a rustup component |
|
e40222d
to
3ae396f
Compare
This comment has been minimized.
This comment has been minimized.
My reading of the remaining CI failure is that indeed some optimizations no longer work out as expected once contracts are added. Advice would be appreciated! |
The point of this PR is to change the MIR, so you just need to I suspect you'll then fail codegen tests, and those may be much more troublesome. |
3ae396f
to
78aad63
Compare
@RalfJung (or others in @rust-lang/miri): what are my next steps now that I see
in the above CI failure logs? Thank you! |
For now, adding |
78aad63
to
38f3d67
Compare
This comment has been minimized.
This comment has been minimized.
Uses the contracts syntax introduced in rust-lang#128045.
38f3d67
to
667454b
Compare
@@ -20,6 +20,6 @@ fn main() { | |||
// CHECK: debug a => [[a:_.*]]; | |||
// We may check other inlined functions as well... | |||
|
|||
// CHECK: {{_.*}} = const Box::<[bool]>( | |||
// CHECK: {{_.*}} = {{(const )?}}Box::<[bool]>( |
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.
Having to change this is problematic, since apparently the intent of the test was to ensure that this indeed turns into a constant.
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.
Oh, I entirely agree with that. I feel like at this point we are rather exploring the impact of adding those contracts than producing final solutions.
This comment has been minimized.
This comment has been minimized.
Updated via `./x.py test mir-opt --bless --stage 1`
667454b
to
bef04bf
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
I am now seeing differences in MIR produced for x86_64 vs aarch64, and I'm not sure how to reconcile that with the current test tooling. That is:
passes, while
fails. Adding in |
What is the difference you are seeing? |
The following, rather large diff is presented to me:
|
Uses the contracts syntax introduced in #128045.