In `BTreeMap::eq`, do not compare the elements if the sizes are different.
Reverts rust-lang/rust#147101 in library/alloc/src/btree/
rust-lang/rust#147101 replaced some instances of code like `a.len() == b.len() && a.iter().eq(&b)` with just `a.iter().eq(&b)`, but the optimization that PR introduced only applies for `TrustedLen` iterators, and `BTreeMap`'s itertors are not `TrustedLen`, so this theoretically regressed perf for comparing large `BTreeMap`/`BTreeSet`s with unequal lengths but equal prefixes, (and also made it so that comparing two different-length `BTreeMap`/`BTreeSet`s with elements whose `PartialEq` impls that can panic now can panic, though this is not a "promised" behaviour either way (cc rust-lang/rust#149122))
Given that `TrustedLen` is an unsafe trait, I opted to not implement it for `BTreeMap`'s iterators, and instead just revert the change. If someone else wants to audit `BTreeMap`'s iterators to make sure they always return the right number of items (even in the face of incorrect user `Ord` impls) and then implement `TrustedLen` for them so that the optimization works for them, then this can be closed in favor of that (or if the perf regression is deemed too theoretical, this can be closed outright).
Example of theoretical perf regression: https://play.rust-lang.org/?version=beta&mode=release&edition=2024&gist=a37e3d61e6bf02669b251315c9a44fe2 (very rough estimates, using `Instant::elapsed`).
In release mode on stable the comparison takes ~23.68µs.
In release mode on beta/nightly the comparison takes ~48.351057ms.
chore: Update annotate-snippets to 0.12.10
This PR updates `annotate-snippets` to `0.12.10`, which [includes a fix](756366223c/CHANGELOG.md (fixed)) that modifies some test output.
Bring back i686-pc-windows-gnullvm target
rust-lang/rust#148751 inadvertently removed i686-pc-windows-gnullvm std build when migrating to native CI runners. Since this change was not agreed upon, we should bring back prebuilt std builds for that target.
There are a few runners that could do it: dist-aarch64-llvm-mingw, dist-x86_64-llvm-mingw, dist-various-1 and dist-various-2.
dist-x86_64-llvm-mingw already takes slightly over 2 hours, so the faster dist-aarch64-llvm-mingw is a better choice.
We can also use dist-various-x job, they don't have llvm-mingw toolchain, but it's trivial to install one.
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#145628 ([std][BTree] Fix behavior of `::append` to match documentation, `::insert`, and `::extend`)
- rust-lang/rust#149241 (Fix armv4t- and armv5te- bare metal targets)
- rust-lang/rust#149470 (compiletest: Prepare ignore/only conditions once in advance, without a macro)
- rust-lang/rust#149507 (Mark windows-gnu* as lacking build with assertions)
- rust-lang/rust#149508 (Prefer helper functions to identify MinGW targets)
- rust-lang/rust#149516 (Stop adding MSYS2 to PATH)
- rust-lang/rust#149525 (debuginfo/macro-stepping test: extend comments)
- rust-lang/rust#149526 (Add myself (mati865) to the review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
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.
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`.
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
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.
Compute jump threading opportunities in a single pass
The current implementation of jump threading walks MIR CFG backwards from each `SwitchInt` terminator. This PR replaces this by a single postorder traversal of MIR. In theory, we could do a full fixpoint dataflow analysis, but this has low returns as we forbid threading through a loop header.
The second commit in this PR modifies the carried state to a lighter data structure. The current implementation uses some kind of `IndexVec<ValueIndex, &[Condition]>`. This is needlessly heavy, as the state rarely ever carries more than a few `Condition`s. The first commit replaces this state with a simpler `&[Condition]`, and puts the corresponding `ValueIndex` inside `Condition`.
The three later commits are perf tweaks.
The sixth commit is the main change. Instead of carrying the goto target inside the condition, we maintain a set of conditions associated with each block, and their consequences in following blocks. Think: if this condition is fulfilled in this block, then that condition is fulfilled in that block. This makes the threading algorithm much easier to implement, without the extra bookkeeping of `ThreadingOpportunity` we had.
Later commits modify that algorithm to shrink the set of duplicated blocks. By propagating fulfilled conditions down the CFG, and trimming costly threads.
Tidying up UI tests [7/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
removed directory `tests/ui/explicit`, `tests/ui/interior-mutability`, `tests/ui/invalid-module-declaration`, tests/ui/invalid-self-argument`
r? Kivooeo
make assoc fn inherit const stability from inherent `const impl` blocks
Pulled out of rust-lang/rust#147893, "Currently, one cannot add any const stability annotations on the individual assoc fns at all, as the specific pass that checks for const stability on const fn seems to run as a HIR visitor [and looks at HIR assoc fn constness, which should be changed to also look at its parent]. I suspect there are things to be cleaned up there."
I was slightly lazy so didn't add the "staged_api using staged_api in implicit const stable context, in const unstable context, in explicit const stable context" tests. nudge me if you want to see those!
Don't suggest unwrap for Result in const
closerust-lang/rust#149316
Regarding `const fn` that returns `Result`, we should avoid suggesting unwrapping. The original issue reported cases where types didn't match, but in practice, such suggestions may also appear when methods are not found, so this PR includes a fix for that case as well.
cmse: do not calculate the layout of a type with infer types
tracking issue: https://github.com/rust-lang/rust/issues/81391
tracking issue: https://github.com/rust-lang/rust/issues/75835
fixes https://github.com/rust-lang/rust/issues/130104
Don't calculate the layout of a type with an infer type (`_`). This now emits `LayoutError::Unknown`, causing an error similar to when any other calling convention is used in this location.
The tests use separate functions because only the first such error in a function body is reported.
r? `@davidtwco` (might need some T-types assistance)
