#[contracts::requires(...)] + #[contracts::ensures(...)] #128045
+1,561
−39
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
Please add a ui test with an attribute proc-macro aux build that conflicts with |
| register( | ||
| sym::contracts_requires, | ||
| SyntaxExtensionKind::Attr(Box::new(contracts::ExpandRequires)), | ||
| ); |
There was a problem hiding this comment.
This macro should be able to use register_attr! above.
There was a problem hiding this comment.
I'm not sure if we actually can, if we want to support arbitrary syntax within the contracts::require(...) -- doesn't register_attr! mandate that the requires expression conform to ast::MetaItem, which imposes restrictions on what the syntax can be, i.e. x > 0 wouldn't work?
There was a problem hiding this comment.
I took a closer look at this, and this is very unfortunate. I don't believe the current builtin macro setup allows for "path segments"-like namespacing (like rustc_contracts::require). I've tried to change the builtin macro support to allow multiple "segments" via SmallVec<[Symbol; 2]>, but as one would expect, that change kept propagating outwards to attributes.
There was a problem hiding this comment.
sorry for my delay in responding here.
@jieyouxu is exactly right.
specifically, register_attr! expands to a SyntaxExtensionKind::LegacyAttr, which is where the conformance to ast::MetaItem is enforced IIRC.
The plan here to support code snippets like x > 0 in a contract form means that we cannot conform to ast::MetaItem.
(In theory I could try to extend the register_attr! macro to support expansion to non LegacyAttr. Is that what you are asking for, @petrochenkov ?)
There was a problem hiding this comment.
@petrochenkov let me know if you want me to make any changes here. Per @pnkfelix comment, using register_attr! would restrict the input of the contract attributes which is not desirable here. Thanks!
There was a problem hiding this comment.
If that is the reason, at the very least a comment is needed to explain that.
There was a problem hiding this comment.
There are comments in the builtin macro implementation. Would you like me to add comments to this file as well?
|
r? compiler |
celinval
reviewed
Jul 23, 2024
|
r? compiler |
|
I don't know that part of the compiler r? @petrochenkov would you like to review this? |
No. |
|
r? compiler |
|
I'll ask T-compiler for another suitable reviewer to take a look at the HIR/MIR parts of the PR, or take over the review. In the mean time, I'll also roll a T-libs reviewer for the libs part. r? jieyouxu |
rustbot
added
the
S-waiting-on-author
celinval
force-pushed
the
rustc-contracts
branch
2 times, most recently
from
722bfe7 to
4fbde37
Compare
This comment has been minimized.
This comment has been minimized.
celinval
force-pushed
the
rustc-contracts
branch
from
4fbde37 to
6971578
Compare
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #135947) made this pull request unmergeable. Please resolve the merge conflicts. |
celinval
force-pushed
the
rustc-contracts
branch
from
6971578 to
c2f671c
Compare
oli-obk
reviewed
Jan 25, 2025
|
☔ The latest upstream changes (presumably #136070) made this pull request unmergeable. Please resolve the merge conflicts. |
fmease
added a commit
to fmease/rust
that referenced
this pull request
Jan 29, 2025
Refactor FnKind variant to hold &Fn Pulling the change suggested in rust-lang#128045 to reduce the impact of changing `Fn` item. r? `@oli-obk`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 29, 2025
Rollup merge of rust-lang#136164 - celinval:chores-fnkind, r=oli-obk Refactor FnKind variant to hold &Fn Pulling the change suggested in rust-lang#128045 to reduce the impact of changing `Fn` item. r? `@oli-obk`
|
@rustbot labels -I-lang-nominated We discussed this in the lang call today and signed off on this as a lang experiment according to our process. Many of us were excited to see this work go forward. @nikomatsakis has volunteered to be the liaison, and @joshtriplett also expressed his interest and willingness to help here. |
rustbot
removed
the
I-lang-nominated
8 tasks
These are hooks to: 1. control whether contract checks are run 2. allow 3rd party tools to intercept and reintepret the results of running contracts.
… to invoke. see test for an example of the kind of injected code that is anticipated here.
…ract lang items includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures. includes post-developed commit: removed tabs that creeped in into rustfmt tool source code. includes post-developed commit, placating rustfmt self dogfooding. includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/ includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures). Rebase Conflicts: - compiler/rustc_parse/src/parser/diagnostics.rs - compiler/rustc_parse/src/parser/item.rs - compiler/rustc_span/src/hygiene.rs Remove contracts keywords from diagnostic messages
…xtensions added earlier.
…ostcondition predicate.
The extended syntax for function signature that includes contract clauses should never be user exposed versus the interface we want to ship externally eventually.
Instead of parsing the different components of a function signature, eagerly look for either the `where` keyword or the function body. - Also address feedback to use `From` instead of `TryFrom` in cranelift contract and ubcheck codegen.
1. Document the new intrinsics. 2. Make the intrinsics actually check the contract if enabled, and remove `contract::check_requires` function. 3. Use panic with no unwind in case contract is using to check for safety, we probably don't want to unwind. Following the same reasoning as UB checks.
This is now a valid expected value.
celinval
force-pushed
the
rustc-contracts
branch
from
c2f671c to
8d841fd
Compare
traviscross
reviewed
Jan 30, 2025
Comment on lines
611
to
614
| /// Allows use of contracts attributes. | ||
| (unstable, rustc_contracts, "CURRENT_RUSTC_VERSION", Some(133866)), | ||
| /// Allows access to internal machinery used to implement contracts. | ||
| (unstable, rustc_contracts_internals, "CURRENT_RUSTC_VERSION", Some(133866)), |
There was a problem hiding this comment.
Suggested change
| /// Allows use of contracts attributes. | |
| (unstable, rustc_contracts, "CURRENT_RUSTC_VERSION", Some(133866)), | |
| /// Allows access to internal machinery used to implement contracts. | |
| (unstable, rustc_contracts_internals, "CURRENT_RUSTC_VERSION", Some(133866)), | |
| /// Allows use of contracts attributes. | |
| (incomplete, contracts, "CURRENT_RUSTC_VERSION", Some(133866)), | |
| /// Allows access to internal machinery used to implement contracts. | |
| (internal, contracts_internals, "CURRENT_RUSTC_VERSION", Some(133866)), |
As a lang experiment, these should go in with the experimental warning. Also, the rustc_ bit should be removed from the feature flag.
There was a problem hiding this comment.
Should I go ahead and rename all usages of RustcContract with just Contract?
I also just noticed that contracts_internals feature should be in fact marked as internal. So I'll do that instead.
Expand these two expressions to include a call to contract checking
This has now been approved as a language feature and no longer needs a `rustc_` prefix. Also change the `contracts` feature to be marked as incomplete and `contracts_internals` as internal.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cc #128044
Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings that culminates in:
-Z contract-checks) that, similar to-Z ub-checks, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,Known issues:
My original intent, as described in the MCP (Contracts: Experimental attributes and language intrinsics compiler-team#759) was to have a rustc-prefixed attribute namespace (like rustc_contracts::requires). But I could not get things working when I tried to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it is called
contracts::requires.Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
fn foo1(x: i32) -> S<{ 23 }> { ... }, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the{ 23 }is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)the intent of
-Z contract-checksis that it behaves like-Z ub-checks, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably,coreandstd). But the current test suite does not actually check that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.