Use the query vtable in `query_feed` plumbing
The `query_feed` function needs to be able to do two important things with (erased) query values: hash them, and debug-print them.
Both of those are things that the query's vtable already knows how to do. So by passing in a vtable to `query_feed`, we can give it a nicer signature, avoid having to unerase values in the function itself, and clean up some caller-side code as well.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#152008 (`rust-analyzer` subtree update)
- rust-lang/rust#151109 (fN::BITS constants for feature float_bits_const)
- rust-lang/rust#151976 (Rename `collect_active_jobs` to several distinct names)
- rust-lang/rust#151691 (compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`)
- rust-lang/rust#151919 (fix: Make `--color always` always print color with `--explain`)
- rust-lang/rust#152017 (Remove `with_no_trimmed_paths` use in query macro)
- rust-lang/rust#152028 (Convert to inline diagnostics in `rustc_driver_impl`)
Convert to inline diagnostics in `rustc_driver_impl`
Converts a crate for rust-lang/rust#151366
This PR is almost completely autogenerated by a hacky script I have locally :)
Remove `with_no_trimmed_paths` use in query macro
We already use `with_no_trimmed_paths!` when calling query descriptors so the extra call generated by the macro is not needed.
fix: Make `--color always` always print color with `--explain`
Fixesrust-lang/rust#151643.
This changes the behaviour of `handle_explain` in `rustc_driver_impl` to always output color when the `--color always` flag is set.
r? @tgross35
compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`
Since it does not make sense to do so. If someone prefers no dynamic stuff, the last thing they want to look for is an .so file. Also add a regression test. Without the fix, the test fails with:
error: test compilation failed although it shouldn't!
--- stderr -------------------------------
error: extern location for no_prefer_dynamic_lib does not exist: .../auxiliary/libno_prefer_dynamic_lib.so
--> .../no-prefer-dynamic-means-no-so.rs:9:5
|
LL | no_prefer_dynamic_lib::return_42();
| ^^^^^^^^^^^^^^^^^^^^^
### Needed by:
- https://github.com/rust-lang/rust/pull/150591 because of https://github.com/rust-lang/rust/issues/151271. But IMHO this PR makes sense on its own.
### Must wait for:
- [x] https://github.com/rust-lang/rust/pull/151695
Rename `collect_active_jobs` to several distinct names
Key renames:
- Function `collect_active_jobs` → `collect_active_jobs_from_all_queries` (method in trait `QueryContext`)
- Constant `COLLECT_ACTIVE_JOBS` → `PER_QUERY_GATHER_ACTIVE_JOBS_FNS` (list of per-query function pointers)
- Function `collect_active_jobs` → `gather_active_jobs` (per-query function in `query_impl::$name`)
- Function `collect_active_jobs` → `gather_active_jobs_inner` (method in `QueryState`)
- Giving these four things distinct names makes it a lot easier to tell them apart!
- The switch from “collect” (all queries) to “gather” (single query) is intended to make the different parts a bit more memorable and searchable; I couldn't think of a more natural way to express this distinction so I settled for two different synonyms.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
fN::BITS constants for feature float_bits_const
Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait.
---
Implementation for rust-lang/rust#151073
Feature flag: `#![feature(float_bits_const)]`
Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value.
Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
Since it does not make sense to do so. If someone prefers no dynamic
stuff, the last thing they want to look for is an `.so` file. Also add a
regression test. Without the fix, the test fails with:
error: test compilation failed although it shouldn't!
--- stderr -------------------------------
error: extern location for no_prefer_dynamic_lib does not exist: .../auxiliary/libno_prefer_dynamic_lib.so
--> .../no-prefer-dynamic-means-no-so.rs:9:5
|
LL | no_prefer_dynamic_lib::return_42();
| ^^^^^^^^^^^^^^^^^^^^^
Fix missing unused_variables lint when using a match guard
Within a binding pattern match guard, only real reads of a bound local impact its liveness analysis - not the fake read that is injected.
Fixesrust-lang/rust#151983
r? compiler
Work around rustfmt giving up on a large expression
- https://github.com/rust-lang/rustfmt/issues/3863
---
In some cases, if rustfmt sees a string literal that is too long for it to comfortably format, it will give up on formatting the entire enclosing expression.
For complex builder expressions, that will prevent auto-formatting for frustratingly large sections of code.
This PR works around a particular occurrence of that phenomenon in `compiler/rustc_interface/src/util.rs`, by splitting a single error message string across multiple lines. This allows rustfmt to successfully auto-format the entire enclosing expression, which is dozens of lines long.
There should be no change to compiler behaviour.
Add codegen test for SLP vectorization
close: rust-lang/rust#142519
This PR adds a codegen regression test for rust-lang/rust#142519. A regression in LLVM to fail to auto-vectorize, leading to significant performance loss.
The SLP vectorizer correctly groups the 4-byte operations into <4 x i8> vectors.
The loop state is maintained in SIMD registers (phi <4 x i8>).
The test remains robust across architectures (AArch64 vs x86_64) by allowing flexible store types (i32 or <4 x i8>).
Move bigint helper tracking issues
Closesrust-lang/rust#85532.
This splits the remainder of the `bigint_helper_methods` tracking issue into three issues:
* `signed_bigint_helpers`: rust-lang/rust#151989
* `widening_mul`: rust-lang/rust#152016
* `const_unsigned_bigint_helpers`: rust-lang/rust#152015
Note that the existing stable methods were merged under the `unsigned_bigint_helpers` feature as part of rust-lang/rust#144494.
Move the `fingerprint_style` special case into `DepKindVTable` creation
I'm a little bit fuzzy on *precisely* why anonymous queries are treated as having `FingerprintStyle::Opaque`, but I'm pretty confident that baking this special case into the query vtable is equivalent to the current behaviour, while being marginally more efficient.
(I believe this special case comes from anonymous queries not having a fingerprint in the first place, so “opaque” is just there to signal that reconstructing a key is impossible.)
Codegen tests for Arm Cortex-R82
This PR adds checks to the `aarch64v8r-unknown-none` target to verify that if the Cortex-R82 CPU is enabled (with `-Ctarget-cpu=cortex-r82`), that the appropriate additional AArch64 features are enabled.
This is important because Cortex-R82 is (currently) the only processor implementing Armv8-R AArch64 and it implements a number of Armv8 features over and above the baseline for the architecture. Many of these features are of interest to safety-critical firmware development (for example `FEAT_RASv1p1`, which adds support for the *RAS Common Fault Injection Model Extension*) and so we anticipate them being enabled when building such firmware.
We are offering these tests upstream in-lieu of a full Cortex-R82 specific target because we understand the Project has a preference for architecture-baseline targets over CPU-specific targets.
~~This PR builds on and requires https://github.com/rust-lang/rust/pull/150863, but we've pulled them out as a separate PR.~~ That PR has been merged.
## Ownership
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
