Add a `TaggedQueryKey` to identify a query instance
This adds back a `TaggedQueryKey` enum which represents a query kind and the associated key. This is used to replace `QueryStackDeferred` and `QueryStackFrameExtra` and the associated lifting operation for cycle errors
This approach has a couple of benefits:
- We only run description queries when printing the query stack trace in the panic handler
- The unsafe code for `QueryStackDeferred` is removed
- Cycle handles have access to query keys, which may be handy
Some further work could be replacing `QueryStackFrame` with `TaggedQueryKey` as the extra information can be derived from it.
tests/debuginfo/basic-stepping.rs: Add lldb test
Also move the FIXME to the source code to avoid duplication, and also suppress harmless warnings that are annoying when you compile manually.
Takes us one step closer towards closing rust-lang/rust#33013.
fixed VecDeque::splice() not filling the buffer correctly when resizing the buffer on start = end range
This PR fixesrust-lang/rust#151758. The issue came from `Splice::move_tail`, which as joboet pointed out:
> The issue is in move_tail, which resizes the buffer, but fails to account for the resulting hole.
The problem with reserving more space through `VecDeque`'s `buf.reserve()` is that it doesn't update `VecDeque`'s `head`, which means that this code in `move_tail`:
```rust
deque.wrap_copy(
deque.to_physical_idx(tail_start),
deque.to_physical_idx(new_tail_start),
self.tail_len,
);
```
could move over the section of data that `tail_start..tail_start + self.tail_len` of the buffer is supposed to be held at to the incorrect destination since all `.to_physical_idx()` is doing is a wrapping add on the `VecDeque`'s head with the passed in `idx` value.
To avoid this I decided to use `VecDeque::reserve` to both allocate more space into the `VecDeque` if necessary and update head appropriately. However, `VecDeque::reserve` internally relies on the `VecDeque`'s `len` field. Earlier in `VecDeque::splice`, it modifies the `VecDeque`'s `len` constructing the drain via `Drain::new` (as it does a `mem::replace` on `deque.len` with the start bound of the passed in `range`). The `VecDeque`'s `len` can also be potentially modified in the earlier `Splice::fill()` call if it does any replacement towards elements within the passed in `range` value for `VecDeque::splice()`. I needed to temporarily restore the `VecDeque`'s `len` to its actual len, so that `VecDeque::reserve` can work properly. Afterward, you can bring back the `VecDeque`'s `len` to what its value was before and fill the gap appropriately with the rest of the `replace_with` content.
r? @joboet
`execute_job` has a single call site in `try_execute_query`. This commit
inlines and removes `execute_job`, but also puts the part that checks
feedable results in its own separate function, `check_feedable`, because
it's a nicely separate piece of logic.
The big win here is that all the code dealing with the `QueryState` is
now together in `try_execute_query`: get the lock, do the lookup, drop
the lock, create the job guard, and complete the job guard. Previously
these steps were split across two functions which I found hard to
follow.
This commit purely moves code around, there are no other changes.
Rename `rustc_middle::lint::diag_lint_level` into `lint_level`
Part of https://github.com/rust-lang/rust/issues/153099.
Renaming back `diag_lint_level` into `lint_level` since the original function was completely replaced and removed.
r? @JonathanBrouwer
Include optional `dso_local` marker for functions in `enum-[match,transparent-extract].rs`
This PR adds some more `dso_local` markers to the `enum-match.rs` and `enum-transparent-extract.rs` test annotations. These markers are added by LLVM when targeting `aarch64-unknown-none` even though they are missing in `aarch64-unknown-linux-gnu`. This is causing a CI error when running the codegen suite on the `aarch64-unknown-none` target for Ferrocene.
This is a follow up of https://github.com/rust-lang/rust/pull/139891.
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#153705 (Always generate generics in delegation that match trait in trait impl scenario)
- rust-lang/rust#153751 (Detect existing turbofish on method calls to suppress useless suggestion)
- rust-lang/rust#153780 (Remove `MTLock`)
- rust-lang/rust#151572 (Fix Hexagon ABI calling convention for small aggregates)
- rust-lang/rust#153725 (Fix that `./x test --no-doc` actually keeps the same behaviour for backwards compatability)
Fix that `./x test --no-doc` actually keeps the same behaviour for backwards compatability
In https://github.com/rust-lang/rust/pull/153143 the `./x test --no-doc` flag was renamed to `--all-targets`. I added a commit that keeps the `--no-doc` flag for backwards compatibility, but unfortunately I forgot to actually keep the behaviour the same, which is fixed by this PR.
r? @Kobzol
Fix Hexagon ABI calling convention for small aggregates
Small structs (<= 64 bits) were being passed with their fields split into separate arguments instead of being packed into register-sized chunks. This caused ABI mismatches.
The fix properly casts small aggregates to consecutive register-sized chunks using Uniform::consecutive(), matching the Hexagon C ABI where small structs are packed into R1:0 register pair.
This fixes tests like extern-pass-TwoU16s.rs and extern-pass-TwoU8s.rs.
Remove `MTLock`
This removes the `MTLock` type and replaces it users with the regular `Lock`. It no longer makes sense now that we don't have a compile-time toggle for parallelism.
Detect existing turbofish on method calls to suppress useless suggestion
`expr_inferred_arg_iter` hardcoded `have_turbofish: false` for `MethodCall` expressions, while the `Path` case properly checked for existing type arguments via `segment.args`. This meant the "consider specifying the generic arguments" suggestion always fired on method calls, even when the user already had a turbofish, producing a suggestion that just rewrote user syntax into fully qualified form without resolving anything.
Fixesrust-lang/rust#153732.
cc @eggyal
Always generate generics in delegation that match trait in trait impl scenario
After rust-lang/rust#151864 there is a change in delegation code generation in `trait impl` cases: after rust-lang/rust#151864 we started to look at user-specified args and generate functions, whose generics may not match the signature of the function that is defined in trait. Such handling of delegation from trait impl is not correct, as the generated function should always have the same generics as its signature function in trait.
This addresses the "Fix generic params generation in trait impl case" future work from rust-lang/rust#151864
r? @petrochenkov
actually make the is-fn test test what it says it tests
r? @lcnr
Previously this test was (apart from the comment) identical to tests/ui/async-await/async-closures/once.rs
editorconfig: css uses tabs
Tidy enforces the fact that css files use tabs, but currently `.editorconfig` says everything that isn't llvm or a Makefile should always use spaces. This PR makes it so all editors that honor `.editorconfig` will use the correct indentation for css files.
unused_macro_rules switched used and unused comments
Incorrect swapping of "used" and "unused".
The lint example:
```rust
#[warn(unused_macro_rules)]
macro_rules! unused_empty {
(hello) => { println!("Hello, world!") }; // This rule is unused
() => { println!("empty") }; // This rule is used
}
fn main() {
unused_empty!(hello);
}
```
It is clearly using the `(hello)` case. Yet it is labeled as "unused".
This PR fixed that small issue and corrects the mistake.
fix(query): Pass Query Key to `value_from_cycle_error`
### Summary:
Pass the query key directly to `value_from_cycle_error` so that `FromCycleError` impls (notably `FnSig`) can use the recovered query's `DefId` instead of relying on `cycle[0]`, which is arbitrarily rotated by the parallel deadlock handler.
As suggested in [#153644 (comment)](https://github.com/rust-lang/rust/pull/153644#issuecomment-4030645331).
Closesrust-lang/rust#153391
r? @nnethercote
cc @zetanumbers
Fix some comments about dataflow analysis.
Mostly in the examples in `initialized.rs`. In particular, the `EverInitializedPlaces` example currently doesn't cover how it's initialization sites that are tracked, rather than local variables (that's the `b_0`/`b_1` distinction in the example.)
r? @cjgillot
Don't add empty target features for target-cpu=native on macOS
LLVM does not support host feature detection (only host cpu detection) on apple platforms. As such, the returned feature string will be empty. Adding this empty string to the target-features attribute results in a verifier error on LLVM 22.
Fix this by not adding the empty string to the target features. The reason why this was not caught by the target-cpu-native test is that it requires a function that adds *some* target features, otherwise the attribute is omitted entirely. We achieve this with a somewhat peculiar construction that enables `neon` if it's already enabled. (This is to avoid enabling it on softfloat targets.)
Fixes https://github.com/rust-lang/rust/issues/153397.
LLVM does not support host feature detection (only host cpu
detection) on apple platforms. As such, the returned feature
string will be empty. Adding this empty string to the target-features
attribute results in a verifier error on LLVM 22.
Fix this by not adding the empty string to the target features.
The reason why this was not caught by the target-cpu-native test
is that it requires a function that adds *some* target features,
otherwise the attribute is omitted entirely. We achieve this with
a somewhat peculiar construction that enables `neon` if it's
already enabled. (This is to avoid enabling it on softfloat targets.)
Guillaume Gomez