library: use strict provenance lints consistently

[hanna-kruppe]

The fuzzy_provenance_casts lint is enabled in most of the standard library, but its identical twin lossy_provenance_casts was not. As discussed in the tracking issue for those lints, there doesn't seem to be any good reason to enable one without the other. This PR applies this principle and as a result removes some unnecessary ptr->int as casts.

It's also preparation for merging the two lints, which removes the option of only enabling fuzzy_provenance_casts.

Tracking issue: #130351

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 8 candidates

[hanna-kruppe]

The CI failure is due to a clippy lint using rustc_hir_typeck to test if an as cast would be possible, and rustc emitting the strict provenance lints during this check. I created rust-lang/rust-clippy#17063 for that, it's not solely a problem of the strict provenance lints. The specific expressions that trigger the bug in the CI job are these two pointer->int transmutes:

• rust/library/core/src/array/drain.rs

  Line 83 in 54333ff

  let len = unsafe { transmute::<*mut T, usize>(self.end_or_len) };

• rust/library/core/src/array/drain.rs

  Line 114 in 54333ff

  transmute::<*mut T, usize>(self.end_or_len)

The "invalid span" warnings seems to caused by a mix of that clippy issue (check_cast uses DUMMY_SPAN because diagnostics are not expected) and the span manipulation in the lints. I created #156850 for another issue with the span manipulation that I discovered while debugging, but I think that one's unrelated (I haven't been able to provoke an invalid span without the clippy issue in the mix).

I didn't find an easy workaround for the clippy bug that I'd be comfortable including in this PR. So I'll try moving the strict provenance lints out of the HIR typechecking path and convert them to normal late lints (edit: opened #156862 for this). So this PR should be ready for review in theory, but can't pass CI until I've either done that or someone finds another fix for rust-lang/rust-clippy#17063

@rustbot blocked

[rustbot]

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.

[hanna-kruppe]

#156862 was merged and fixed the previous CI failure as expected. Another job failed after rebase but that was spurious (actions runner died midway), so: @rustbot ready

[jhpratt]

r? jhpratt

@bors r+

[rust-bors]

📌 Commit fed6279 has been approved by jhpratt

It is now in the queue for this repository.

[rust-bors]

⌛ Testing commit fed6279 with merge 6402f0d...

Workflow: https://github.com/rust-lang/rust/actions/runs/26694683369

[JonathanBrouwer]

💔 This PR failed tests as part of a rollup
After fixing the problem, consider running a try job for the failed job before re-approving
@bors r-

Link to failure:
#157167 (comment)

[rust-bors]

This pull request was unapproved.

This PR was contained in a rollup (#157167), which was unapproved.

Auto build was cancelled due to unapproval. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/26694683369

View changes since this unapproval

[hanna-kruppe]

Added a commit that should fix that failure. @bors ready

[rust-bors]

Unknown command "ready". Run @bors help to see available commands.

[hanna-kruppe]

@rustbot ready