[stable] Revert "Build shared LLVM lib for windows-gnullvm"
This reverts commit 1d1280a.
Looks like this causes problems (rust-lang/rust#155268) with certain LLVM bin tools not finding `libLLVM` on `*-windows-gnullvm`. This PR is a _minimal_ revert to return us to known state to alleviate time pressure to investigate.
This reverts commit 1d1280aae1.
Looks like this causes problems with certain LLVM bin tools not finding
`libLLVM` on `*-windows-gnullvm`. This commit is a _minimal_ revert to
return us to known state to alleviate time pressure to investigate.
Fixes https://github.com/rust-lang/rust-clippy/pull/16605
This PR addresses the 6.2% compilation performance regression introduced
by the original `allow_unwrap_types` implementation (which natively
allocated AST strings on every `unwrap` call via `bumpalo`).
The implementation has been refactored to pre-resolve types securely
without a performance penalty:
**Pre-Resolution Cache via `LateLintPass`**: Instead of executing
`ty.to_string()` and `lookup_path_str` inside the immediate
`unwrap_expect_used` hot check for every method call encountered,
`allow-unwrap-types` configuration strings are now parsed exactly *once*
per crate compilation during the `LateLintPass::check_crate` hook in
`clippy_lints/src/methods/mod.rs`.
**`DefId` Native Storage**: The parsed `DefId` representations are
stored in-memory using highly efficient caching maps directly on the
main `Methods` struct:
- `unwrap_allowed_ids: FxHashSet<DefId>`: Allows instant O(1) lookups
for standard types.
- `unwrap_allowed_aliases: Vec<DefId>`: Tracks type aliases requiring
signature substitution checking later.
**Execution Relief**: Inside `unwrap_expect_used::check()`, string
manipulation is completely removed and `ty::Adt` checking uses
lightning-fast `.contains(&adt.did())` operations to categorically avoid
regression allocation loops. This implementation strongly parallels the
pre-resolution type-routing logic in
`clippy_config::types::create_disallowed_map` without altering the core
`clippy.toml` config requirements.
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/16652#issuecomment-3976671413)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
changelog: none
I'm ignoring the fact that there's a feature to change the behavior of
the syntax. I just want to help prevent confusing the people reading
the docs.
(cherry picked from commit eef4363403)
I'm ignoring the fact that there's a feature to change the behavior of
the syntax. I just want to help prevent confusing the people reading
the docs.
(cherry picked from commit 092f0ca1bd)
This implementation was added recently in f12288ec26
("TryFrom<integer> for bool") but used an old feature gate and
stabilization version. Update to reflect when these were actually added.
(cherry picked from commit 02b516afd9)
Move `freeze_*` methods to `OpenOptionsExt2`
Move the unstable `freeze_last_access_time` and `freeze_last_write_time` from `OpenOptionsExt` to a new `OpenOptionsExt2` trait. This should fixrust-lang/rust#153486.
Don't add empty target features for target-cpu=native on macOS
LLVM does not support host feature detection (only host cpu detection) on apple platforms. As such, the returned feature string will be empty. Adding this empty string to the target-features attribute results in a verifier error on LLVM 22.
Fix this by not adding the empty string to the target features. The reason why this was not caught by the target-cpu-native test is that it requires a function that adds *some* target features, otherwise the attribute is omitted entirely. We achieve this with a somewhat peculiar construction that enables `neon` if it's already enabled. (This is to avoid enabling it on softfloat targets.)
Fixes https://github.com/rust-lang/rust/issues/153397.
2 commits in e8eb8435d5cad936237a1ee798c2f983624d0825..f2d3ce0bd7f24a49f8f72d9000448f8838c4e850
2026-03-06 12:51:00 -0600 to 2026-03-21 06:43:08 -0500
- [beta 1.95] Fix symlink_and_directory when running in a long target dir name (rust-lang/cargo#16776)
- [beta 1.95] Update tar to 0.4.45 (rust-lang/cargo#16770)
[beta] Don't look for non-type-level assoc consts when checking trait object types
Beta backport of PR rust-lang/rust#153738. Said PR can't just be rebased onto beta as it needs slight adjustments due to PR RUST-153050 not being part of beta.
Directly fixesrust-lang/rust#153731.
~~Blocked on backport acceptance by T-compiler~~ (done) (nomination happened / nomination procedure happens over at rust-lang/rust#153738, not here).
The unstable features of the `test` crate used to be default-enabled,
and manually disabled when building the beta and stable channels. Commit
dae8ea92a7 flipped that to default-disabled, only enabled for nightly
and dev channels.
However, this broke miri testing on the beta/stable channels, because it
also uses unstable features -- which should be fine to enable just for
its own sysroot build. Now the `test` build script makes that happen by
noticing the `MIRI_CALLED_FROM_SETUP` environment variable.
(cherry picked from commit 30d7ed4c47)
Work around a false `err.emit();` type error in rust-analyzer
For whatever reason, rust-analyzer doesn't see that these calls to `err.emit();` are diverging, so the trailing semicolon makes r-a complain about a type mismatch between `()` and some other type.
Removing the trailing semicolon makes no functional difference (because the emit still unwinds the stack), but seems to be enough to allow rust-analyzer to see that emitting an error returns `!` in these cases, which silences the false error.
bors