-
Notifications
You must be signed in to change notification settings - Fork 14.1k
Rollup of 8 pull requests #149531
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 8 pull requests #149531
Conversation
Also rationalise the settings, and copy in the thumb base defaults, rather than just import them, because these aren't M-profile microcontrollers and may not want to always have the same settings.
The binary crate is a tiny stub; all of the logic and tests should be in the library crate. Disabling unit tests for the binary crate makes `x test compiletest` less noisy.
This commit also renames the confusing `NotADirective` outcome, and fuses it with `External` into a single `NotHandledHere` outcome.
Rust no longer requires MSYS2 tools like make.
I've been procrastinating long enough.
…nieu [std][BTree] Fix behavior of `::append` to match documentation, `::insert`, and `::extend` Resolves rust-lang#145614
…metal, r=davidtwco Fix armv4t- and armv5te- bare metal targets These two targets currently force on the LLVM feature `+atomics-32`. LLVM doesn't appear to actually be able to emit 32-bit load/store atomics for these targets despite this feature, and emits calls to a shim function called `__sync_lock_test_and_set_4`, which nothing in the Rust standard library supplies. See [#t-compiler/arm > __sync_lock_test_and_set_4 on Armv5TE](https://rust-lang.zulipchat.com/#narrow/channel/242906-t-compiler.2Farm/topic/__sync_lock_test_and_set_4.20on.20Armv5TE/with/553724827) for more details. Experimenting with clang and gcc (as logged in that zulip thread) shows that C code cannot do atomic load/stores on that architecture either (at least, not without a library call inserted). So, the safest thing to do is probably turn off `+atomics-32` for these two Tier 3 targets. I asked `@Lokathor` and he said he didn't even use atomics on the `armv4t-none-eabi`/`thumbv4t-none-eabi` target he maintains. I was unable to reach `@QuinnPainter` for comment for `armv5te-none-eabi`/`thumbv5te-none-eabi`. The second commit renames the base target spec `spec::base::thumb` to `spec::base::arm_none` and changes `armv4t-none-eabi`/`thumbv4t-none-eabi` and `armv5te-none-eabi`/`thumbv5te-none-eabi` to use it. This harmonises the frame-pointer and linker options across the bare-metal Arm EABI and EABIHF targets. You could make an argument for harmonising `armv7a-none-*`, `armv7r-none*` and `armv8r-none-*` as well, but that can be another PR.
…eyouxu compiletest: Prepare ignore/only conditions once in advance, without a macro Compiletest has historically handled `ignore-*` and `only-*` directives in an extremely confusing way that makes the code hard to understand and hard to modify. This PR therefore takes an important step away from that older design by instead evaluating a set of named boolean "conditions" in advance, and then using those conditions to help determine whether a particular directive should cause its test to be ignored or not. As usual, there's more cleanup that I want to do here, but I've left most of it for future work to help keep this PR manageable. r? jieyouxu
…s, r=clubby789 Mark windows-gnu* as lacking build with assertions Knowing that `x86_64-pc-windows-gnu` has no builds with assertions, I have just copied it as `x86_64-pc-windows-gnullvm` and called a day. Obviously it should have been `false`, sorry for that. While at it, also fix `x86_64-pc-windows-gnu`.
Prefer helper functions to identify MinGW targets
Stop adding MSYS2 to PATH Rust no longer requires MSYS2 provided tools like make.
…r=jieyouxu debuginfo/macro-stepping test: extend comments Those `#locN` markers look like they are debuginfo compiletest magic (since `#break` is debuginfo compiletest magic). However, they are actually just magic strings used by the `check` commands in the test itself. This threw me off when I looked at the test (prompted by a CI failure), so let's leave a comment for the next poor soul that ends up lost in this test. Also, for some reason the lldb instructions do not check for `#loc6`, unlike the gdb instructions. I do not know of an lldb version that actually makes the test pass (do we even run it with lldb at all on CI?), so I won't try to add a check for loc6, but let's at least add a comment to increase the chance that someone more knowledgeable about lldb and our test suite notices this in the future.
…=Kivooeo Add myself (mati865) to the review rotation I've been procrastinating long enough.
|
Rollup of everything. @bors r+ rollup=never p=5 |
|
@bors try jobs=x86_64-msvc-1,i686-msvc-1,x86_64-mingw-1,test-various,armhf-gnu,aarch64-apple,dist-various-1 |
This comment has been minimized.
This comment has been minimized.
Rollup of 8 pull requests try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: test-various try-job: armhf-gnu try-job: aarch64-apple try-job: dist-various-1
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 4ad239f415 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 4ad239f (parent) -> 63b1db0 (this PR) Test differencesShow 1507 test diffsStage 0
Stage 1
Stage 2
Additionally, 1502 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 63b1db05801271e400954e41b8600a3cf1482363 --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 |
|
Finished benchmarking commit (63b1db0): 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.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -3.4%)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: 469.27s -> 468.853s (-0.09%) |
Successful merges:
::appendto match documentation,::insert, and::extend#145628 ([std][BTree] Fix behavior of::appendto match documentation,::insert, and::extend)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup