#[contracts::requires(...)] + #[contracts::ensures(...)] #128045
Conversation
|
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
|
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 |
|
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 |
|
@pnkfelix @celinval I'm trying to use this, and ran into an issue with "stacking" attributes. For example, the following causes a macro expansion error: #![feature(contracts)]
#[core::contracts::requires(true)]
#[core::contracts::requires(true)] // This line causes an error.
#[core::contracts::ensures(|_| true)]
#[core::contracts::ensures(|_| true)]
fn some_function() {}Running it like so causes an error: $ cargo +nightly test --test simple_test
|
4 | #[core::contracts::requires(true)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected one of `.`, `?`, `where`, `{`, or an operatorIs this expected? Am I doing something wrong? More info about the toolchain: |
|
Hi @mkovaxx, the current implementation support up to one occurrence of each contract attribute per item. |
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.