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.
Remove mutation from macro path URL construction
Resolves the `FIXME` in `generate_macro_def_id_path`.
The old code mutated `path` to build the URL — popping the macro name, pushing an interned filename, then restoring the original at the end. None of that was necessary. A slice pattern gives us `module_path` and `last` without touching the original, and `push_fmt(format_args!(...))` writes the filename directly into the URL builder, same as `make_href` already does.
Also tightened the error guards: the original `path.len() < 2` is now two distinct checks with messages that describe the actual failure (empty path vs. single-element path missing the crate prefix).
r? @GuillaumeGomez
Fix mem::conjure_zst panic message to use any::type_name instead
Use `crate::any::type_name::<T>()` instead of `stringify!(T)` in the
runtime panic message of `conjure_zst` , so the actual type name (e.g.
`i32`) is shown rather than the literal string `[T]`.
rustc_public: remove the `CrateDefItems` trait
This trait feels sus since its documentation says it's for 'retrieving all items from a definition' however it only provides an `associated_items` method (??), which I believe should only be valid for `impl`s and `trait`s.
Improved security section in rustdoc for `current_exe`
A few improvements to the security section of the docs about `current_exe`
0. The explanatory link <https://vulners.com/securityvulns/SECURITYVULNS:DOC:22183> is ~~broken~~ not directly very helpful in understanding the risk.
1. It basically previously says to never trust the result, which is IMO too pessimistic to be helpful. It's worth understanding the behavior but if you have a use case to re-exec the current program, which is not uncommon, this is a reasonable way to do it.
2. The particular risk is about setuid/setgid processes that shouldn't fully trust the user that spawned them.
3. IMO the most important risk with this function is that the invoker can control argv and PATH, so I made this more explicit. (Many unixes, including Linux, don't rely on them in the implementation, but some do.)
4. The previous text about TOCTOU and races is IMO not really coherent: if an attacker can write to the location where you're going to re-exec, they can fundamentally control what program is executed. They don't need to race with your execution of current_exe, and there is no up-front check.
5. Briefly explain the pattern of CVE-2009-1894: on Linux, depending on system configuration, an attacker who can create hardlinks to the executable can potentially control `/proc/self/exe`. On modern Linux this should normally require permission to write to the executable.
I did some web research for "argv0 vulnerability" and similar terms and didn't find anything else we should be documenting here. (There are issues about argc=0 but those should be prevented by memory safety in Rust.)
I found what the link seemed to be pointing to in <https://vulners.com/cve/CVE-2009-1894>, which talks about confusing a setuid program by creating a hardlink to its exe. I think this is in very particular circumstances something people should still be concerned about: a setuid program on a machine with `fs.protected_hardlinks = 0`. I don't think this justifies warning people not to use the function at all.
cc @mgeisler
Clarify a confusing green-path function
The current name of this function, `try_load_from_disk_and_cache_in_memory`, is confusing on a number of levels:
- Trying to mark the node green is load-bearing even for queries that never cache to disk.
- It will only return None if it fails to mark the query green; the subsequent parts always return Some.
- If it cannot load a value from disk, it will obtain a value by invoking the query provider.
- It is not actually responsible for storing values in the in-memory cache; that is handled by an outer layer.
This PR therefore:
- Hoists the try-mark-green out of that function, making the function always return a value.
- Renames the function to `load_from_disk_or_invoke_provider_green `.
- Renames a few other local variables in passing.
There should be no change to compiler behaviour.
Stop using `LinkedGraph` in `lexical_region_resolve`
There are only two users of the older `LinkedGraph` data structure, and this is one.
It turns out that this diagnostic-related code doesn't need any non-trivial graph operations (since it does its own graph traversal); it just needs the ability to get a list of in-edges or out-edges (constraints) for any particular node. That's easy enough to do with a simple custom data structure.
Inspired by https://github.com/rust-lang/rust/pull/152621, which wants to make changes to `LinkedGraph` that wouldn't make sense for this use-site.
explicit tail calls: support indirect arguments
tracking issue: https://github.com/rust-lang/rust/issues/112788
After discussion in https://github.com/rust-lang/rust/issues/144855, I was wrong and it is actually possible to support tail calls with `PassMode::Indirect { on_stack: false, .. }` arguments.
Normally an indirect argument with `on_stack: false` would be passed as a pointer into the caller's stack frame. For tail calls, that would be unsound, because the caller's stack frame is overwritten by the callee's stack frame.
Therefore we store the argument for the callee in the corresponding caller's slot. Because guaranteed tail calls demand that the caller's signature matches the callee's, the corresponding slot has the correct type.
To handle cases like the one below, the tail call arguments must first be copied to a temporary, and can only then be copied to the caller's argument slots.
```rust
// A struct big enough that it is not passed via registers.
pub struct Big([u64; 4]);
fn swapper(a: Big, b: Big) -> (Big, Big) {
become swapper_helper(b, a);
}
```
---
I'm not really familiar with MIR and what tricks/helpers we have, so I'm just cobbling this together. Hopefully we can arrive at something more elegant.
Trevor Gross