Rollup of 14 pull requests #146125
Merged
Rollup of 14 pull requests #146125
Conversation
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
Replace unimplemented()! with a more helpful compiler error.
Normally, changes to rustfmt go into the separate repo. But, in this case, the bug is introduced in a local change and therefore isn't present in the rustfmt repo.
…file outside of local_sources add test against crashing with --html-after-content file correctly add --html-after-content to env not args formatting fix for rustdoc-call-locations-after-content/rmake.rs Use local crate source file as default span in `render_call_locations` - avoids unwrapping the first file added to the source map as a local file in `href_from_span` move test to tests/rustdoc-gui, rename to scrape_examples_ice test link is correct use rustdocflags, rename path in example, track lock file factor out duplicate function calls use compile-flags to make sure the after.html file is actually included in the rustdoc call fix goml go-to path increment assert-count in sidebar-source-code.goml adjust crate-search width in search-result-display.goml renamed Bar in scrape_examples_ice test make crate name shorter ..
This updates tests/codegen-llvm/issues/issue-118306.rs to pass also after llvm/llvm-project#155415
…kingjubilee stabilize c-style varargs for sysv64, win64, efiapi, aapcs This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to rust-lang#145954. **Previous (combined) PR description:** This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates. The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](rust-lang#136946 (comment)) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR): - "stdcall" for win32 targets **for non-variadic functions** - "C" for everything else This had been previously stabilized *without FCP* in rust-lang#116161, which got reverted in rust-lang#136897. There was also a "fun" race condition involved with the system ABI being [added](rust-lang#119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang#116161. There was a question raised [here](rust-lang#116161 (comment)) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me. Fixes rust-lang#100189 Cc `@rust-lang/lang` # Stabilization report > ## General design > ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? AFAIK there is no RFC. The tracking issues are - rust-lang#100189 - rust-lang#136946 > ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The only controversial point is whether "system" ABI functions should support variadics. - Pro: This allows crates like windows-rs to consistently use "system", see e.g. microsoft/windows-rs#3626. - Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](rust-lang#136946 (comment)). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those. Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do ```rust extern "system" { // put all the things here } ``` and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there). (I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.) > ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](rust-lang#44930). > ## Has a Call for Testing period been conducted? If so, what feedback was received? > > Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results". There was no call for testing. A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics. > ## Implementation quality All rustc does here is forward the ABI to LLVM so there's lot a lot to say here... > ### Summarize the major parts of the implementation and provide links into the code (or to PRs) > > An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>. The check for allowed variadic ABIs is [here](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126). The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/compiler/rustc_target/src/spec/abi_map.rs#L82-L85). > ### Summarize existing test coverage of this feature > > Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing. > > Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time. > > - What does the test coverage landscape for this feature look like? > - Tests for compiler errors when you use the feature wrongly or make mistakes? > - Tests for the feature itself: > - Limits of the feature (so failing compilation) > - Exercises of edge cases of the feature > - Tests that checks the feature works as expected (where applicable, `//@ run-pass`). > - Are there any intentional gaps in test coverage? > > Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.). Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64: - rust-lang#144359 - rust-lang#144379 We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.) The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`. > ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? None that I am aware of. > ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None that I am aware of. > ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization `@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature. > ### Which tools need to be adjusted to support this feature. Has this work been done? > > Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs. Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here. > ## Type system and execution rules > ### What compilation-time checks are done that are needed to prevent undefined behavior? > > (Be sure to link to tests demonstrating that these tests are being done.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### What updates are needed to the reference/specification? (link to PRs when they exist) - rust-lang/reference#1936 > ## Common interactions > ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. > ### What other unstable features may be exposed by this feature? None.
…rors add span to struct pattern rest (..) Struct pattern rest (`..`) did not retain span information compared to normal fields. This patch adds span information for it. The motivation of this patch comes from when I implemented this PR for Clippy: rust-lang/rust-clippy#15000 (comment) It is possible to get the span of the Et cetera in a bit roundabout way, but I thought this would be nicer.
Update target spec metadata of Arm64EC Windows and Trusty targets Update outdated target spec metadata in the following targets. - Arm64EC Windows (`arm64ec-pc-windows-msvc`) is "tier 2 without host tools" since rust-lang#126039 and supports `std` since before that, but metadata currently says that is tier 3 and has unknown `std` support status. - Trusty targets (`{aarch64,armv7,x86_64}-unknown-trusty`) support `std` since rust-lang#136842 (and I confirmed they can be compiled with `-Zbuild-std=std`), but metadata currently says that has no `std` support. Mentioning `@dpaoliello` as [arm64ec-pc-windows-msvc target-maintainer](https://doc.rust-lang.org/nightly/rustc/platform-support/arm64ec-pc-windows-msvc.html#target-maintainers). Mentioning `@randomPoison` `@ahomescu` as [Trusty target maintainers](https://doc.rust-lang.org/nightly/rustc/platform-support/trusty.html#target-maintainers).
Add compiler error when trying to use concat metavar expr in repetitions ## Disclaimer This is my first PR to rust, so if I missed/could improve something about this PR, please excuse and tell me! ## The improvement The [metavar_expr_concat feature](rust-lang#124225) currently does not seem to support nested repetitions, and throws an ICE without much explanation if the relevant code path is hit. This PR adds a draft compiler error that attempts to explain the issue. I am not 100% sure what all the ways of triggering this error are, so the message is currently pretty generic, please do correct me if there's something wrong with it or it could be improved. Thank you for you time! Fixes rust-lang#140479.
…ta, r=GuillaumeGomez rustdoc-search: skip loading unneeded fnData Fixes rust-lang#146063 (probably) Based on the test I ran, it seems like most of the CPU time is being spent loading function signature data. This PR should avoid that. https://notriddle.com/rustdoc-html-demo-12/skip-loading-function-data/doc/std/index.html
constify impl Try for ControlFlow Related to: rust-lang#74935
fix a constness ordering bug in rustfmt Normally, changes to rustfmt go into the separate repo. But, in this case, the bug is introduced in a local change and therefore isn't present in the rustfmt repo. Related to: rust-lang#146071 Fixes rust-lang/rustfmt#6619.
…h-simple-test, r=GuillaumeGomez fix rustdoc `render_call_locations` panicking because of default span `DUMMY_SP` pointing at non local-source file fixes rust-lang#144752 related to/builds on rust-lang#145008 bevy still crashes in the same way as rust-lang#144752 when building docs on nightly, and from what I can tell the cause seems to be the following (copied from zulip [#t-rustdoc > docs on nightly with example scrapes crash](https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/docs.20on.20nightly.20with.20example.20scrapes.20crash)): > render_call_locations tries to [find](https://github.com/rust-lang/rust/blob/84a17470220e7adf249b18d7c0178dfbede89462/src/librustdoc/html/render/mod.rs#L2816) the source span of a call to add as an example, but the example files are never actually in the source map from what I can tell, and so it falls back to the default span, which points at the first file in the source map. > Now, the issue that guillaume mentions [here](rust-lang#145008) adds new files to the source map in order to get them into the dep info, and that leads to some files, namely docs-rs/trait-tags.html in the case of bevy because it's added with --html-after-content, being added before any source files, so then the default span points at them, and when href_from_span tries to find the [source file](https://github.com/rust-lang/rust/blob/84a17470220e7adf249b18d7c0178dfbede89462/src/librustdoc/html/render/context.rs#L368) corresponding to the span, the file doesn't belong to local_sources, and it short circuits. > This can be fixed by just not using DUMMY_SP as the default span and calculating, for example, the crates root source file as the span, because I'm not entirely sure what the href from that span is actually used for; it's not what links to the example in the end. > I think the proper way of fixing this would be to make sure the example files are part of the local_sources or at least the source map, but I don't know nearly enough about rust internals to be able to figure out how to fix that. I've included a test that's mostly copied from rust-lang#145008's test with the addition of `--html-after-content after.html` in the `RUSTDOCFLAGS`, which panics on master in conjunction with the `-Zrustdoc-scrape-examples` cargo flag. cc `@GuillaumeGomez`
Make `Parser::parse_for_head` public for rustfmt usage Similar to rust-lang#138511, I want to add [dioxus rsx](https://dioxuslabs.com/learn/0.6/reference/rsx) formatting to [my rustfmt fork](https://github.com/tucant/rustfmt) and it would be much easier if that method would be public. Thanks.
…1-dead Remove dead code stemming from an old effects desugaring CC rust-lang#132374, rust-lang#133443. r? fee1-dead
Add maintainer for VxWorks Hi, This adds me as a target maintainer for VxWorks. I am currently a member of the VxWorks compiler team and I am actively working on improving rust support for VxWorks. Thanks!
Adjust issue-118306.rs test after LLVM change This updates tests/codegen-llvm/issues/issue-118306.rs to pass also after llvm/llvm-project#155415
…neration, r=notriddle Fix search index generation Fixes this issue: ``` error: couldn't generate documentation: failed to read column from disk: data consumer error: missing field `unknown number` at line 1 column 8 | = note: failed to create or modify "build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/search.index/entry/": failed to read column from disk: data consumer error: missing field `unknown number` at line 1 column 8 warning: `theme_css` (lib doc) generated 1 warning error: could not document `theme_css` ``` The problem was that a conversion was forgotten for the `ItemType` enum. Thanks a lot to `@janis-bhm!` r? `@lolbinarycat`
improve process::abort rendering in Miri backtraces Also, avoid using the `sys` function directly in the panic machinery -- that seems like an unnecessary layering violation.
rustbot
added
A-rustdoc-search
|
@bors r+ p=5 rollup=never |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
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 a2c8b0b (parent) -> 94722ca (this PR) Test differencesShow 73 test diffsStage 1
Stage 2
Additionally, 66 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 94722cabf4983abcbe5088c1b8e81517ba2a7126 --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 |
|
📌 Perf builds for each rolled up PR:
previous master: a2c8b0b92c In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Sep 2, 2025
|
Finished benchmarking commit (94722ca): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -3.5%, secondary 2.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 465.026s -> 464.662s (-0.08%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
render_call_locationspanicking because of default spanDUMMY_SPpointing at non local-source file #146091 (fix rustdocrender_call_locationspanicking because of default spanDUMMY_SPpointing at non local-source file)Parser::parse_for_headpublic for rustfmt usage #146094 (MakeParser::parse_for_headpublic for rustfmt usage)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup