-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #125665
Rollup of 5 pull requests #125665
Conversation
This comment -- "by default we ignore everything in the repository" -- was added in rust-lang#65939 when rustfmt was first being introduced for this repository and (briefly) every directory was ignored. Since then lots of directories have opted in to formatting, so it is no longer true.
Some are too long, some aren't complete sentences, some are complete sentences but don't bother with an upper case letter at the start. All annoying and hurt readability.
It's reasonable to want to, but in the current implementation this causes multiple problems. - All the `rmake.rs` files are formatted every time even when they haven't changed. This is because they get whitelisted unconditionally in the `OverrideBuilder`, before the changed files get added. - The way `OverrideBuilder` works, if any files gets whitelisted then no unmentioned files will get traversed. This is surprising, and means that the `rmake.rs` entries broke the use of explicit paths to `x fmt`, and also broke `GITHUB_ACTIONS=true git check --fmt`. The commit removes the `rmake.rs` entries, fixes the formatting of a couple of files that were misformatted (not previously caught due to the `GITHUB_ACTIONS` breakage), and bans `!`-prefixed entries in `rustfmt.toml` because they cause all these problems.
…ct, r=davidtwco NVPTX: Avoid PassMode::Direct for args in C abi Fixes rust-lang#117480 I must admit that I'm confused about `PassMode` altogether, is there a good sum-up threads for this anywhere? I'm especially confused about how "indirect" and "byval" goes together. To me it seems like "indirect" basically means "use a indirection through a pointer", while "byval" basically means "do not use indirection through a pointer". The return used to keep `PassMode::Direct` for small aggregates. It turns out that `make_indirect` messes up the tests and one way to fix it is to keep `PassMode::Direct` for all aggregates. I have mostly seen this PassMode mentioned for args. Is it also a problem for returns? When experimenting with `byval` as an alternative i ran into [this assert](https://github.com/rust-lang/rust/blob/61a3eea8043cc1c7a09c2adda884e27ffa8a1172/compiler/rustc_codegen_llvm/src/abi.rs#L463C22-L463C22) I have added tests for the same kind of types that is already tested for the "ptx-kernel" abi. The tests cannot be enabled until something like rust-lang#117458 is completed and merged. CC: ``@RalfJung`` since you seem to be the expert on this and have already helped me out tremendously CC: ``@RDambrosio016`` in case this influence your work on `rustc_codegen_nvvm` ``@rustbot`` label +O-NVPTX
…ngs-cmdline-stability, r=jieyouxu Migrate `run-make/allow-warnings-cmdline-stability` to `rmake.rs` Part of rust-lang#121876. r? ``@jieyouxu``
Add a "Setup Python" action for github-hosted runners and remove unnecessary `CUSTOM_MINGW` environment variable The Setup Python action isn't strictly necessary ([even on Windows](rust-lang#125584)) but it is [recommend by GitHub](https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#specifying-a-python-version). The `CUSTOM_MINGW` environment variable is redundant now as it's always set for mingw and always unset otherwise. try-job: x86_64-mingw try-job: x86_64-mingw try-job: dist-x86_64-msvc try-job: dist-x86_64-mingw
…, r=lcnr Make `ProofTreeBuilder` actually generic over `Interner` Self-explanatory. Also renamed `ecx.tcx()` to `ecx.interner()`. r? lcnr
…aumeGomez rustfmt fixes The `rmake.rs` entries in `rustfmt.toml` are causing major problems for `x fmt`. This PR removes them and does some minor related cleanups. r? ``@GuillaumeGomez``
@bors r+ rollup=never=5 |
@bors r+ rollup=never p=5 |
💡 This pull request was already approved, no need to approve it again.
|
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 8c4db851a7 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (274499d): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary -2.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 2.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 668.572s -> 668.568s (-0.00%) |
visiting for weekly rustc-perf triage helloworld is sole primary regression. (also the 30-day history shows the story for helloworld to be quite a bit more complicated than what is presented by the effects of this single PR, there are lots of spikes mixed in there) @rustbot label: +perf-regression-triaged |
Successful merges:
run-make/allow-warnings-cmdline-stability
tormake.rs
#125573 (Migraterun-make/allow-warnings-cmdline-stability
tormake.rs
)CUSTOM_MINGW
environment variable #125590 (Add a "Setup Python" action for github-hosted runners and remove unnecessaryCUSTOM_MINGW
environment variable)ProofTreeBuilder
actually generic overInterner
#125598 (MakeProofTreeBuilder
actually generic overInterner
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup