Rollup of 12 pull requests #122389
Merged
Rollup of 12 pull requests #122389
Conversation
This file contains 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
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Which is a variant of [`unix_sigpipe-list.rs`][1] but where a string is used instead of an identifier. This makes it more similar to the proper form `#[unix_sigpipe = "sig_dfl"]` and thus more likely to be written by users by mistake. Also rename the first test to be more in line with the terminology of [The Reference][2]. [1]: https://github.com/rust-lang/rust/blob/master/tests/ui/attributes/unix_sigpipe/unix_sigpipe-list.rs [2]: https://doc.rust-lang.org/reference/attributes.html#meta-item-attribute-syntax
The tests show that the code generation currently uses the least significant bits of <iX x N> vector masks when converting to <i1 xN>. This leads to an additional left shift operation in the assembly for x86, since mask operations on x86 operate based on the most significant bit. On aarch64 the left shift is followed by a comparison against zero, which repeats the sign bit across the whole lane. The exception, which does not introduce an unneeded shift, is simd_bitmask, because the code generation already shifts before truncating. By using the "C" calling convention the tests should be stable regarding changes in register allocation, but it is possible that future llvm updates will require updating some of the checks. This additional instruction would be removed by the fix in rust-lang#104693, which uses the most significant bit for all mask operations.
Adapts rust for llvm/llvm-project@9997e03.
…rum,onur-ozkan [bootstrap] Move the `split-debuginfo` setting to the per-target section As described in rust-lang#112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple. This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example). However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`). rust-lang#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well. This PR does **not** implement `@ehuss's` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change. --- After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now. This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple. --- If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
…ed-simd-instructions, r=workingjubilee Add tests for the generated assembly of mask related simd instructions. The tests show that the code generation currently uses the least significant bits of <iX x N> vector masks when converting to <i1 xN>. This leads to an additional left shift operation in the assembly for x86, since mask operations on x86 operate based on the most significant bit. The exception is simd_bitmask, which already uses the most-significant bit. This additional instruction would be removed by the changes in rust-lang#104693, which makes all mask operations consistently use the most significant bits. By using the "C" calling convention the tests should be stable regarding changes in register allocation, but it is possible that future llvm updates will require updating some of the checks.
…=clubby789 validate `builder::PATH_REMAP` self-explanatory r? clubby789
…etrochenkov Detect truncated DepGraph files I suspect that the following issues are caused by truncated incr comp files: * rust-lang#120582 * rust-lang#121499 * rust-lang#122210 We fail with an allocation failure or capacity overflow in this case because we assume that the ending bytes of an DepGraph file are the lengths of arrays. If the file has somehow been truncated then the ending bytes are probably some of our varint encoding, which tries to eliminate zero bytes, so interpreting a random 8 bytes as an array length has a very high chance of producing a byte capacity over `isize::MAX`. Now theoretically since rust-lang#119510 merged I have fixed the out-of-disk issues and yet in rust-lang#120894 (comment) I still see some decoding failures that look like out-of-disk ICEs, for example https://crater-reports.s3.amazonaws.com/beta-1.77-1/beta-2024-02-10/gh/scottfones.aoc_2022/log.txt So this PR should ensure that we get an ICE that clearly identifies if the file in question is truncated.
… r=albertlarsan68 bootstrap: Don't eagerly format verbose messages We `format!` a lot of messages which are only used when we are at some level of verbosity - do this lazily instead
…notriddle rustdoc: fix up old test `tests/rustdoc/line-breaks.rs` had several issues: 1. It used `//`@count`` instead of `// `@count`` (notice the space!) which gets treated as a `ui_test` directive instead of a `htmldocck` one. `compiletest` didn't flag it as an error because it's allowlisted ([rust-lang#121561](rust-lang#121561)) presumably precisely because of this test. And before the compiletest→ui_test migration, these directives must've been ignored, too, because … 2. … the checks themselves no longer work either: The count of `<br>`s is actually 0 in all 3 cases because – well – we no longer generate any `<br>`s inside `<pre>`s. Since I don't know how to ``@count`` `\n`s instead of `<br>`s, I've turned them into ``@matches`.` Btw, I don't know if this test is still desirable or if we have other tests that cover this (I haven't checked). r? rustdoc
…li-obk tests: Add ui/attributes/unix_sigpipe/unix_sigpipe-str-list.rs Which is a variant of [`unix_sigpipe-list.rs`][1] but where a string is used instead of an identifier. This makes it more similar to the proper form `#[unix_sigpipe = "sig_dfl"]` and thus more likely to be written by users by mistake. Having a test for this case gives peace of mind. Also rename the first test to be more in line with the terminology of [The Reference][2]. [1]: https://github.com/rust-lang/rust/blob/master/tests/ui/attributes/unix_sigpipe/unix_sigpipe-list.rs [2]: https://doc.rust-lang.org/reference/attributes.html#meta-item-attribute-syntax Tracking issue: rust-lang#97889
…w, r=lcnr Fix stack overflow with recursive associated types fixes rust-lang#122364
…paste_fix, r=oli-obk Fix discriminant_kind copy paste from the pointee trait case r? `@oli-obk`
…-ozkan Properly rebuild rustbooks Fixes rust-lang#122367 If the book was out of date but the tool was up to date, this would evaluate to `!(false || true)` == `!true` == `false` and not rebuild.
Fix typo in lib.rs of proc_macro I believe I discovered a typo in the documentation of TokenStream while writing a procedural macro.
llvm-wrapper: adapt for LLVM API changes Adapts rust for llvm/llvm-project@9997e03. `@rustbot` label: +llvm-main r? `@durin42`
rustbot
added
A-query-system
rustbot
added
T-rustdoc
|
@bors r+ rollup=never p=12 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 7de1a1f6db In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Mar 12, 2024
|
Finished benchmarking commit (6b1e5d9): 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)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 672.776s -> 675.268s (0.37%) |
|
hmm, I suspect... |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (465c5e3): comparison URL. Overall result: ❌ regressions - no action neededInstruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 672.776s -> 674.055s (0.19%) |
|
Looking at the history chart, I would say that this is just noise: @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
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:
split-debuginfosetting to the per-target section #121754 ([bootstrap] Move thesplit-debuginfosetting to the per-target section)builder::PATH_REMAP#122081 (validatebuilder::PATH_REMAP)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup