Add contracts for all functions in Alignment

[tautschnig]

Uses the contracts syntax introduced in #128045.

[rustbot]

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 (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[jieyouxu]

You could also tag contracts-related PRs with F-contracts in the future via

@rustbot label: +F-contracts

in a comment / PR description.

[tgross35]

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?

[jieyouxu]

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)

[Noratrieb]

I'll libs nominate this for discussion (this should only be discussed after the contracts people mentioned above have replied).

[celinval]

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 ub_checks will interact.

[Noratrieb]

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?

[tautschnig]

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.

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?

[tautschnig]

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?

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.

[tgross35]

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?

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 std. I think we could also use a policy page in the library dev guide (https://std-dev-guide.rust-lang.org) giving guidelines for their use, based on the outcome of any discussion that happens.

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.

[Amanieu]

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.

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

   Compiling object v0.36.7
   Compiling std v0.0.0 (/checkout/library/std)
   Compiling cc v1.2.0
   Compiling compiler_builtins v0.1.151
error[E0015]: cannot call non-const function `build_check_ensures::<usize, {closure@library/core/src/mem/mod.rs:480:53: 480:69}>` in constant functions
   --> library/core/src/mem/mod.rs:480:28
    |
480 | #[cfg_attr(not(bootstrap), core::contracts::ensures(|result: &usize| result.is_power_of_two()))]
    |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const closure in constant functions
   --> library/core/src/mem/mod.rs:480:28
    |
480 | #[cfg_attr(not(bootstrap), core::contracts::ensures(|result: &usize| result.is_power_of_two()))]
    |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const function `build_check_ensures::<alignment::Alignment, {closure@library/core/src/ptr/alignment.rs:48:13: 48:33}>` in constant functions
  --> library/core/src/ptr/alignment.rs:47:32
   |
47 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
   |  ________________________________^
48 | |             |result: &Alignment| result.as_usize().is_power_of_two()))]
   | |_____________________________________________________________________^
   |
   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const closure in constant functions
  --> library/core/src/ptr/alignment.rs:47:32
   |
47 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
   |  ________________________________^
48 | |             |result: &Alignment| result.as_usize().is_power_of_two()))]
   | |_____________________________________________________________________^
   |
   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const function `build_check_ensures::<Option<alignment::Alignment>, {closure@library/core/src/ptr/alignment.rs:62:13: 63:41}>` in constant functions
  --> library/core/src/ptr/alignment.rs:61:32
   |
61 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
   |  ________________________________^
62 | |             move
63 | |             |result: &Option<Alignment>| align.is_power_of_two() == result.is_some() &&
64 | |             (result.is_none() || result.unwrap().as_usize() == align)))]
   | |______________________________________________________________________^
   |
   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const closure in constant functions
  --> library/core/src/ptr/alignment.rs:61:32
   |
61 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
   |  ________________________________^
62 | |             move
63 | |             |result: &Option<Alignment>| align.is_power_of_two() == result.is_some() &&
64 | |             (result.is_none() || result.unwrap().as_usize() == align)))]
   | |______________________________________________________________________^
   |
   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error: cannot call non-const intrinsic `contract_check_requires` in constant functions
  --> library/core/src/ptr/alignment.rs:85:32
   |
85 |     #[cfg_attr(not(bootstrap), core::contracts::requires(align.is_power_of_two()))]
   |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0015]: cannot call non-const function `build_check_ensures::<alignment::Alignment, {closure@library/core/src/ptr/alignment.rs:87:13: 88:33}>` in constant functions
  --> library/core/src/ptr/alignment.rs:86:5
   |
86 | /     #[cfg_attr(not(bootstrap), core::contracts::ensures(
87 | |             move
88 | |             |result: &Alignment| result.as_usize() == align &&
89 | |             result.as_usize().is_power_of_two()))]
   | |__________________________________________________^
   |
   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const closure in constant functions
  --> library/core/src/ptr/alignment.rs:86:5
   |
86 | /     #[cfg_attr(not(bootstrap), core::contracts::ensures(
87 | |             move
88 | |             |result: &Alignment| result.as_usize() == align &&
89 | |             result.as_usize().is_power_of_two()))]
   | |__________________________________________________^
   |
   = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const function `build_check_ensures::<usize, {closure@library/core/src/ptr/alignment.rs:107:13: 107:29}>` in constant functions
   --> library/core/src/ptr/alignment.rs:106:32
    |
106 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
    |  ________________________________^
107 | |             |result: &usize| result.is_power_of_two()))]
    | |______________________________________________________^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const closure in constant functions
   --> library/core/src/ptr/alignment.rs:106:32
    |
106 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
    |  ________________________________^
107 | |             |result: &usize| result.is_power_of_two()))]
    | |______________________________________________________^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const function `build_check_ensures::<NonZero<usize>, {closure@library/core/src/ptr/alignment.rs:117:13: 118:38}>` in constant functions
   --> library/core/src/ptr/alignment.rs:116:32
    |
116 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
    |  ________________________________^
117 | |             move
118 | |             |result: &NonZero<usize>| result.get().is_power_of_two() &&
119 | |             result.get() == self.as_usize()))]
    | |____________________________________________^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const closure in constant functions
   --> library/core/src/ptr/alignment.rs:116:32
    |
116 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
    |  ________________________________^
117 | |             move
118 | |             |result: &NonZero<usize>| result.get().is_power_of_two() &&
119 | |             result.get() == self.as_usize()))]
    | |____________________________________________^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error: cannot call non-const intrinsic `contract_check_requires` in constant functions
   --> library/core/src/ptr/alignment.rs:146:32
    |
146 |     #[cfg_attr(not(bootstrap), core::contracts::requires(self.as_usize().is_power_of_two()))]
    |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0015]: cannot call non-const function `build_check_ensures::<u32, {closure@library/core/src/ptr/alignment.rs:148:13: 149:27}>` in constant functions
   --> library/core/src/ptr/alignment.rs:147:5
    |
147 | /     #[cfg_attr(not(bootstrap), core::contracts::ensures(
148 | |             move
149 | |             |result: &u32| *result < usize::BITS &&
150 | |             (1usize << *result) == self.as_usize()))]
    | |_____________________________________________________^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const closure in constant functions
   --> library/core/src/ptr/alignment.rs:147:5
    |
147 | /     #[cfg_attr(not(bootstrap), core::contracts::ensures(
148 | |             move
149 | |             |result: &u32| *result < usize::BITS &&
150 | |             (1usize << *result) == self.as_usize()))]
    | |_____________________________________________________^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const function `build_check_ensures::<usize, {closure@library/core/src/ptr/alignment.rs:182:13: 183:29}>` in constant functions
   --> library/core/src/ptr/alignment.rs:181:32
    |
181 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
    |  ________________________________^
182 | |             move
183 | |             |result: &usize| *result > 0 &&
184 | |             *result == !(self.as_usize() -1) &&
185 | |             self.as_usize() & *result == self.as_usize()))]
    | |_________________________________________________________^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

error[E0015]: cannot call non-const closure in constant functions
   --> library/core/src/ptr/alignment.rs:181:32
    |
181 |       #[cfg_attr(not(bootstrap), core::contracts::ensures(
    |  ________________________________^
182 | |             move
183 | |             |result: &usize| *result > 0 &&
184 | |             *result == !(self.as_usize() -1) &&
185 | |             self.as_usize() & *result == self.as_usize()))]
    | |_________________________________________________________^
    |
    = note: calls in constant functions are limited to constant functions, tuple structs and tuple variants

For more information about this error, try `rustc --explain E0015`.

[celinval]

I wonder if we should add rustc_const_stable_indirect to contract functions instead. @rust-lang/wg-const-eval?

[RalfJung]

Which functions would that affect?

Ah, #136925 anyway needs to be resolved first.

[celinval]

This doesn't feel right. I don't think you should add rustc_const_unstable here and below.

[tautschnig]

If I don't do this I get:

error: const function that might be (indirectly) exposed to stable cannot use `#[feature(contracts)]`
  --> library/core/src/ptr/alignment.rs:82:5
   |
82 | /     #[cfg_attr(not(bootstrap), core::contracts::ensures(
83 | |             |result: &Alignment| result.as_usize() == align &&
84 | |             result.as_usize().is_power_of_two()))]
   | |__________________________________________________^
   |
help: if the function is not (yet) meant to be exposed to stable, add `#[rustc_const_unstable]` (this is what you probably want to do)
   |
82 +     #[rustc_const_unstable(feature = "...", issue = "...")]
83 |     #[cfg_attr(not(bootstrap), core::contracts::ensures(
   |
help: otherwise, as a last resort `#[rustc_allow_const_fn_unstable]` can be used to bypass stability checks (this requires team approval)
   |
82 +     #[rustc_allow_const_fn_unstable(contracts)]
83 |     #[cfg_attr(not(bootstrap), core::contracts::ensures(
   |

[tgross35]

Since this is still a draft and has failing tests:

@rustbot author

[tautschnig]

Since this is still a draft and has failing tests:

@rustbot author

CI is expected to pass once the fix for #136925 lands.

[RalfJung]

This will make the MIR of these functions significantly bigger, right? It's going to be cleaned up eventually once contract_checks() is expanded to false, but that might be too late for a bunch of MIR inliner decisions. Cc @saethlin @scottmcm

[scottmcm]

Question from ignorance on my part: how do we encode contracts? Are they in statements/terminators, or in some other communication channel?

[saethlin]

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 Alignment type has become a lot less perf-sensitive since I polymorphized RawVec, and as Celina points out in the doc there is an obvious symmetry between the well-designed contracts and the pile of hacks I've driven forward for the ub_checks feature. I managed to land nearly all the UB checks I wanted with a collective <1% compile time overhead. It took some work to get there, so contracts might need some work too. We'll see.

[celinval]

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 Alignment type has become a lot less perf-sensitive since I polymorphized RawVec, and as Celina points out in the doc there is an obvious symmetry between the well-designed contracts and the pile of hacks I've driven forward for the ub_checks feature. I managed to land nearly all the UB checks I wanted with a collective <1% compile time overhead. It took some work to get there, so contracts might need some work too. We'll see.

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 std-debug which would allow users to compile against debug friendly std library.

[RalfJung]

I kinda wish there was a rustup component std-debug which would allow users to compile against debug friendly std library.

-Zbuild-std is a project goal for 2025h1, so hopefully it will not be too long until users can just build a debug-friendly std.