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.

[bors]

☔ The latest upstream changes (presumably #148167) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

⚠️ #[miri::intrinsic_fallback_is_spec] must only be used if the function actively checks for all UB cases,
and explores the possible non-determinism of the intrinsic.

cc @rust-lang/miri

⚠️ #[rustc_allow_const_fn_unstable] needs careful audit to avoid accidentally exposing unstable
implementation details on stable.

cc @rust-lang/wg-const-eval

[tautschnig]

@RalfJung I believe this is ready to go back to S-waiting-on-review.

[celinval]

@rustbot ready

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tautschnig]

@bors try @rust-timer queue

[rust-bors]

@tautschnig: 🔑 Insufficient privileges: not in try users

[saethlin]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 061e529 (061e5294bd1ede721004372c2f0b8a76f042fa86, parent: 8205e6b75ec656305ac235d4726d2c7a1ddcef14)

[rust-timer]

Finished benchmarking commit (061e529): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	1
Regressions ❌ (secondary)	0.4%	[0.3%, 0.8%]	5
Improvements ✅ (primary)	-1.0%	[-1.3%, -0.7%]	2
Improvements ✅ (secondary)	-1.3%	[-1.3%, -1.3%]	1
All ❌✅ (primary)	-0.6%	[-1.3%, 0.2%]	3

Max RSS (memory usage)

Results (primary -1.4%, secondary 3.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.4%	[3.4%, 3.4%]	1
Regressions ❌ (secondary)	3.5%	[1.7%, 5.3%]	7
Improvements ✅ (primary)	-3.7%	[-3.8%, -3.7%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.4%	[-3.8%, 3.4%]	3

Cycles

Results (secondary -2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-2.8%, -2.1%]	3
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.2%]	5
Regressions ❌ (secondary)	0.1%	[0.0%, 0.2%]	2
Improvements ✅ (primary)	-1.1%	[-1.1%, -1.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-1.1%, 0.2%]	6

Bootstrap: 475.886s -> 473.036s (-0.60%)
Artifact size: 390.36 MiB -> 390.45 MiB (0.02%)