Rollup of 12 pull requests#153183
Merged
rust-bors[bot] merged 25 commits intorust-lang:mainfrom Feb 28, 2026
Merged
Conversation
Remove somewhat obvious comment about executing attacker-controlled programs. Be more clear the examples are not exhaustive.
To see if this helps with <rust-lang#153127>.
…affleLapkin explicit tail calls: support indirect arguments tracking issue: rust-lang#112788 After discussion in rust-lang#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.
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 rust-lang#152621, which wants to make changes to `LinkedGraph` that wouldn't make sense for this use-site.
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.
…dsmtm Force a CI LLVM stamp bump To see if this helps with rust-lang#153127.
…iper 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
rustc_public: rewrite `bridge_impl` to reduce boilerplate It looks better.
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.
…essage, r=RalfJung 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]`.
…, r=GuillaumeGomez 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
…oboet Recover feature lang_items for emscripten Fixes rust-lang#152469 (comment)
…r=petrochenkov Print path root when printing path Extracted from rust-lang#152996. r? petrochenkov
…rcote 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.
rustbot
added
A-query-system
rustbot
added
T-compiler
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
Contributor
Author
|
Trying commonly failed jobs |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 27, 2026
Rollup of 12 pull requests try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Member
|
@bors p=6 |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 27, 2026
…uwer Rollup of 12 pull requests Successful merges: - #151143 (explicit tail calls: support indirect arguments) - #153012 (Stop using `LinkedGraph` in `lexical_region_resolve`) - #153175 (Clarify a confusing green-path function) - #153179 (Force a CI LLVM stamp bump) - #150828 (Improved security section in rustdoc for `current_exe`) - #152673 (rustc_public: rewrite `bridge_impl` to reduce boilerplate) - #152674 (rustc_public: remove the `CrateDefItems` trait) - #153073 (Fix mem::conjure_zst panic message to use any::type_name instead) - #153117 (Remove mutation from macro path URL construction) - #153128 (Recover feature lang_items for emscripten) - #153138 (Print path root when printing path) - #153159 (Work around a false `err.emit();` type error in rust-analyzer)
Contributor
Contributor
Author
|
@bors cancel |
Contributor
|
Auto build cancelled. Cancelled workflows: The next pull request likely to be tested is #153183. |
This comment has been minimized.
This comment has been minimized.
rust-bors
bot
added
merged-by-bors
Contributor
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 3a70d0349f In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 3a70d03 (parent) -> 67aec36 (this PR) Test differencesShow 40 test diffsStage 1
Stage 2
Additionally, 14 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 67aec36df76a7b67b71a8ee47684467e16f1847e --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (67aec36): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (secondary -2.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -3.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 480.016s -> 480.397s (0.08%) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
LinkedGraphinlexical_region_resolve#153012 (Stop usingLinkedGraphinlexical_region_resolve)current_exe#150828 (Improved security section in rustdoc forcurrent_exe)bridge_implto reduce boilerplate #152673 (rustc_public: rewritebridge_implto reduce boilerplate)CrateDefItemstrait #152674 (rustc_public: remove theCrateDefItemstrait)err.emit();type error in rust-analyzer #153159 (Work around a falseerr.emit();type error in rust-analyzer)r? @ghost
Create a similar rollup