Merge and reframe strict_provenance_lints by hanna-kruppe · Pull Request #157575 · rust-lang/rust

hanna-kruppe · 2026-06-07T14:30:21Z

There does not seem to be any good reason to have separate lints for ptr2int and int2ptr casts. The main reason to enable this lint is to help with replacing as casts with strict provenance APIs (if possible) or explicit provenance APIs (when needed). That applies equally to both directions.

Merging the lints requires coming up with new name and lint explanation. This is a good chance to reconsider the purpose and messaging of the lints which have been essentially unchanged since the early days of the "strict provenance experiment". For reasons described below, I called the merged lint implicit_provenance_casts, rewrote its explanation from scratch, and made some changes to diagnostics.

First, the lint is not (only) about strict provenance any more. While strict provenance is often the best fix, migrating as casts to exposed provenance APIs also silences the lint. The exposed provenance APIs aren't any better for Miri and CHERI, but at least provenance considerations are made explicit, not picked up as side effect of the as keyword. (Banning use of exposed provenance APIs can be done with clippy's existing disallowed_methods lint.)

Second, provenance is now officially part of the language and prominently explained in the std::ptr documentation. The new lint refers to those docs and is more consistent with them.

Third, while strict provenance is encouraged whenever possible, exposed provenance is also part of the language and here to stay. Indeed, if we eventually enable the lint by default and make it cargo fix-able to keep the ecosystem migration manageable, we may want to suggest exposed provenance APIs to err on the side of not introducing UB. Thus, I made the diagnostics more neutral and descriptive. I've kept the suggestions that introduce strict provenance APIs, but we may want to reconsider this later.

Tracking issue: #130351

rustbot · 2026-06-07T16:37:03Z

r? @mu001999

rustbot has assigned @mu001999.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 73 candidates
Random selection from 20 candidates

hanna-kruppe · 2026-06-07T16:41:34Z

Not sure what the right process for renaming unstable lints. Does it need a lang FCP or is that only for new stable lints?

Also: cc @RalfJung

RalfJung · 2026-06-07T20:28:17Z

Since this is unstable it doesn't need heavy process.

However, we should ensure that the direction we are taking this is aligned with where t-lang wants this to go. Can you extend the PR description so it briefly recaps what the existing lints are and what they do? Then we can nominate that for t-lang to get their feedback.

Actually an easier approach might be for me to become the champion for these lints, so I can approve changes to them. I'll ask about that on Zulip.

rustbot · 2026-06-12T19:16:10Z

This PR was rebased onto a different main 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.

There does not seem to be any good reason to have separate lints for ptr2int and int2ptr casts. The main reason to enable this lint is to help with replacing `as` casts with strict provenance APIs (if possible) or explicit provenance APIs (when needed). That applies equally to both directions. Merging the lints requires coming up with new name and lint explanation. This is a good chance to reconsider the purpose and messaging of the lints which have been essentially unchanged since the early days of the "strict provenance experiment". For reasons described below, I called the merged lint `implicit_provenance_casts`, rewrote its explanation from scratch, and made some changes to diagnostics. First, the lint is not (only) about strict provenance any more. While strict provenance is often the best fix, migrating `as` casts to exposed provenance APIs also silences the lint. The exposed provenance APIs aren't any better for Miri and CHERI, but at least provenance considerations are made *explicit*, not picked up as side effect of the `as` keyword. (Banning use of exposed provenance APIs can be done with clippy's existing `disallowed_methods` lint.) Second, provenance is now officially part of the language and prominently explained in the `std::ptr` documentation. The new lint refers to those docs and is more consistent with them. Third, while strict provenance is encouraged whenever possible, exposed provenance is also part of the language and here to stay. Indeed, if we eventually enable the lint by default and make it `cargo fix`-able to keep the ecosystem migration manageable, we may want to suggest exposed provenance APIs to err on the side of not introducing UB. Thus, I made the diagnostics more neutral and descriptive. I've kept the suggestions that introduce strict provenance APIs, but we may want to reconsider this later.

RalfJung

Thanks for your patience! I'm finally back from my trip and can start catching up with my backlog.

Mostly minor comments, but I am kind of concerned about the suggestions these lints emit. That's pre-existing though -- it does not block this PR, but I am not sure we want to stabilize this as-is.

@rustbot author

View changes since this review

RalfJung · 2026-06-25T21:11:55Z

+    /// The `implicit_provenance_casts` lint detects integer-to-pointer and pointer-to-integer casts
+    /// that rely on [*Exposed Provenance*][exposed-provenance].


This sounds like it only detects those int/ptr casts that rely on exposed provenance -- but really, they all do.

Suggested change

/// The `implicit_provenance_casts` lint detects integer-to-pointer and pointer-to-integer casts

/// that rely on [*Exposed Provenance*][exposed-provenance].

/// The `implicit_provenance_casts` lint detects integer-to-pointer and pointer-to-integer casts.

RalfJung · 2026-06-25T21:12:32Z

+    ///
+    /// However, there are situations where exposed provenance is required or following the strict
+    /// provenance model requires major refactorings. In those cases, it's still useful to replace
+    /// the `as` casts with explicit use of exposed provenance APIs and a comment explaining why


Suggested change

/// the `as` casts with explicit use of exposed provenance APIs and a comment explaining why

/// the `as` casts with equivalent explicit use of exposed provenance APIs and a comment explaining why

RalfJung · 2026-06-25T21:19:54Z

 LL -     let addr: usize = &x as *const u8 as usize;
 LL +     let addr: usize = (&x as *const u8).addr();


This suggestion seems kind of dangerous -- it is almost always wrong to just apply this, because the cast back to a pointer somewhere else in the code also needs to be adjusted. Do we really want such a suggestions?

RalfJung · 2026-06-25T21:20:13Z

This doesn't seem worth a test

rustbot · 2026-06-25T21:21:17Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

This comment has been minimized.

Sign in to view

hanna-kruppe force-pushed the merge-strict-provenance-lints branch from d8b8b2f to 6e531ef Compare June 7, 2026 15:08

hanna-kruppe marked this pull request as ready for review June 7, 2026 16:36

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 7, 2026

rustbot assigned mu001999 Jun 7, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 7, 2026

mu001999 assigned RalfJung and unassigned mu001999 Jun 8, 2026

This comment has been minimized.

Sign in to view

rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

hanna-kruppe force-pushed the merge-strict-provenance-lints branch from 0274a30 to fda7bff Compare June 12, 2026 19:22

rustbot removed has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2026

RalfJung reviewed Jun 25, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 25, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Merge and reframe strict_provenance_lints#157575

Merge and reframe strict_provenance_lints#157575
hanna-kruppe wants to merge 1 commit into
rust-lang:mainfrom
hanna-kruppe:merge-strict-provenance-lints

hanna-kruppe commented Jun 7, 2026 •

edited by rustbot

Loading

Uh oh!

This comment has been minimized.

rustbot commented Jun 7, 2026

Uh oh!

hanna-kruppe commented Jun 7, 2026

Uh oh!

RalfJung commented Jun 7, 2026 •

edited

Loading

Uh oh!

This comment has been minimized.

rustbot commented Jun 12, 2026

Uh oh!

This comment has been minimized.

RalfJung left a comment •

edited by rustbot

Loading

Uh oh!

RalfJung Jun 25, 2026

Uh oh!

RalfJung Jun 25, 2026

Uh oh!

RalfJung Jun 25, 2026

Uh oh!

RalfJung Jun 25, 2026

Uh oh!

rustbot commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

		/// The `implicit_provenance_casts` lint detects integer-to-pointer and pointer-to-integer casts
		/// that rely on [Exposed Provenance][exposed-provenance].

	/// the `as` casts with explicit use of exposed provenance APIs and a comment explaining why
	/// the `as` casts with equivalent explicit use of exposed provenance APIs and a comment explaining why

		LL - let addr: usize = &x as *const u8 as usize;
		LL + let addr: usize = (&x as *const u8).addr();

Uh oh!

Uh oh!

Conversation

hanna-kruppe commented Jun 7, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Jun 7, 2026

Uh oh!

hanna-kruppe commented Jun 7, 2026

Uh oh!

RalfJung commented Jun 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

rustbot commented Jun 12, 2026

Uh oh!

This comment has been minimized.

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 25, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 25, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 25, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 25, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

hanna-kruppe commented Jun 7, 2026 •

edited by rustbot

Loading

RalfJung commented Jun 7, 2026 •

edited

Loading

RalfJung left a comment •

edited by rustbot

Loading