Upgrade elsa to the newest version.
This was locked to 1.7.1 because of an error in the elsa release process that has since been fixed. Upgrading has the advantage that the elsa code runs properly in miri, at least with tree borrows.
This was spawned from https://github.com/rust-lang/rust/issues/135870#issuecomment-2612470540
Shard AllocMap Lock
This improves performance on many-seed parallel (-Zthreads=32) miri executions from managing to use ~8 cores to using 27-28 cores, which is about the same as what I see with the data structure proposed in https://github.com/rust-lang/rust/pull/136105 - I haven't analyzed but I suspect the sharding might actually work out better if we commonly insert "densely" since sharding would split the cache lines and the OnceVec packs locks close together. Of course, we could do something similar with the bitset lock too.
Either way, this seems like a very reasonable starting point that solves the problem ~equally well on what I can test locally.
r? `@RalfJung`
The reason this test passed previously is not because it was working as intended, but because prior to the previous commit we did not resolve the `use` at all!
Now, `use self as _` is invalid code anyway (it prints E0429), and because we fallback to the value namespace if we can't resolve in the type namespace (which is a reasonable behavior), this test now actually fails.
I don't think we want to change the fallback, so I removed `use self as _` and instead added a new test, where the value can be resolved in the type namespace.
I have no idea what the original writer of the code thought but the logic just seems backwards. We should not exclude a file/directory if it is equal to an include! This also meant that we had to add a `root == path` check so this stuff will actually work, which in turn meant excludes (of root files) no longer worked...
Also rename if to `rust-analyzer.files.exclude`, because it can exclude files as well.
Display of integers without raw pointers and without overflowing_literals
The benchmarks as is measure formatting speed of literals. The first commit `black_box`-es input to simulate runtime speed instead.
The second commit replaces `unsafe` pointer optimizations with plain array indices. The performance is equivalent on Apple M1. Needs peer review on Intel.
Happy to do the 128-bit version too if such change is welcome.
Explicitly choose x86 softfloat/hardfloat ABI
Part of https://github.com/rust-lang/rust/pull/135408:
Instead of choosing this based on the target features listed in the target spec, make that choice explicit.
All built-in targets are being updated here; custom (JSON-defined) x86 (32bit and 64bit) softfloat targets need to explicitly set `rustc-abi` to `x86-softfloat`.
Add a couple of missing `ensure_sufficient_stacks`
r? `@saethlin` I hope you didn't spend time on this already.
(I couldn't sleep, opened `check_tail_calls`, there was a single call where it could happen, might as well fix it)
This PR adds a couple of missing `ensure_sufficient_stack`s:
- one in `check_tail_calls` that prevented the #135709 backport on some targets.
- after that was fixed, the test still didn't pass starting at 4MB, so I also added one in `check_unsafety` and that made it pass.
I didn't add an `rmake` test purposefully limiting the min stack size on `issue-74564-if-expr-stack-overflow.rs`, but we could if we wanted to.
On `apple-aarch64-darwin`, this is enough to make `RUST_MIN_STACK=$((1024*1024*3)) ./x test tests/ui --test-args tests/ui/issues/issue-74564-if-expr-stack-overflow.rs` pass for me locally, and it does stack overflow otherwise.
Target modifiers (special marked options) are recorded in metainfo
Target modifiers (special marked options) are recorded in metainfo and compared to be equal in different linked crates.
PR for this RFC: https://github.com/rust-lang/rfcs/pull/3716
Option may be marked as `TARGET_MODIFIER`, example: `regparm: Option<u32> = (None, parse_opt_number, [TRACKED TARGET_MODIFIER]`.
If an TARGET_MODIFIER-marked option has non-default value, it will be recorded in crate metainfo as a `Vec<TargetModifier>`:
```
pub struct TargetModifier {
pub opt: OptionsTargetModifiers,
pub value_name: String,
}
```
OptionsTargetModifiers is a macro-generated enum.
Option value code (for comparison) is generated using `Debug` trait.
Error example:
```
error: mixing `-Zregparm` will cause an ABI mismatch in crate `incompatible_regparm`
--> $DIR/incompatible_regparm.rs:10:1
|
LL | #![crate_type = "lib"]
| ^
|
= help: the `-Zregparm` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
= note: `-Zregparm=1` in this crate is incompatible with `-Zregparm=2` in dependency `wrong_regparm`
= help: set `-Zregparm=2` in this crate or `-Zregparm=1` in `wrong_regparm`
= help: if you are sure this will not cause problems, use `-Cunsafe-allow-abi-mismatch=regparm` to silence this error
error: aborting due to 1 previous error
```
`-Cunsafe-allow-abi-mismatch=regparm,reg-struct-return` to disable list of flags.