Rollup of 5 pull requests
Successful merges:
- #63492 (Remove redundancy from the implementation of C variadics.)
- #64589 (Differentiate AArch64 bare-metal targets between hf and non-hf.)
- #64799 (Fix double panic when printing query stack during an ICE)
- #64824 (No StableHasherResult everywhere)
- #64884 (Add pkg-config to dependency list if building for Linux on Linux)
Failed merges:
r? @ghost
No StableHasherResult everywhere
This removes the generic parameter on `StableHasher`, instead moving it to the call to `finish`. This has the side-effect of making all `HashStable` impls nicer, since we no longer need the verbose `<W: StableHasherResult>` that previously existed -- often forcing line wrapping.
This is done for two reasons:
* we should avoid false "generic" dependency on the result of StableHasher
* we don't need to codegen two/three copies of all the HashStable impls when they're transitively used to produce a fingerprint, u64, or u128. I haven't measured, but this might actually make our artifacts somewhat smaller too.
* Easier to understand/read/write code -- the result of the stable hasher is irrelevant when writing a hash impl.
Fix double panic when printing query stack during an ICE
On the latest nightly, any call to `bug` or `span_bug` will result in two panics - the first one as a normal result of calling `bug` / `span_bug`, and the second as a result of trying to print the query stack from the panic handler. This is caused by the query-printing code attempting to acquire a lock on `HandlerInnder`, which is still being held by `bug`.
This PR moves the actual panic out of `HandlerInner`, into `Handler`. This allows us to release the lock on `HandlerInner` before triggering the panic, ensuring that the panic handler will be able to acquire the lock if necessary.
Remove redundancy from the implementation of C variadics.
This cleanup was first described in https://github.com/rust-lang/rust/issues/44930#issuecomment-497163539:
* AST doesn't track `c_variadic: bool` anymore, relying solely on a trailing `CVarArgs` type in fn signatures
* HIR doesn't have a `CVarArgs` anymore, relying solely on `c_variadic: bool`
* same for `ty::FnSig` (see tests for diagnostics improvements from that)
* `{hir,mir}::Body` have one extra argument than the signature when `c_variadic == true`
* `rustc_typeck` and `rustc_mir::{build,borrowck}` need to give that argument the right type (which no longer uses a lifetime parameter, but a function-internal scope)
* `rustc_target::abi::call` doesn't need special hacks anymore (since it never sees the `VaListImpl` now, it's all inside the body)
r? @nagisa / @rkruppe cc @dlrobertson @oli-obk
added more context for duplicate lang item errors (fixes#60561)
Some more information about #60561 -- these errors are pretty common when one works in restrictive environments with `no_std` or customized `std`, but they don't provide much context for debugging, as any transitive dependency could have brought in `std` crate. With that, currently, one needs to use something like `cargo tree` and investigate transitive dependencies one by one.
It'll be more helpful to know at least the crate that uses `std` (which `cargo tree` doesn't show) to pin down this investigation when debugging.
I'm not sure what the best way to get this context is inside rustc internals (I'm new to them). I found that `all_crate_nums` query returns the crates in some dependency order, so printing out the name of the preceding crate seems to do the trick. But I welcome suggestions if this can be done in a better way.
Also adds an unstable flag to disable the ICE
(`-Zsuppress-const-validation-back-compat-ice`) so that nightly users do
not have to revert to a previous nightly if their code causes
disagreement between the validators.
check_match: improve diagnostics for `let A = 2;` with `const A: i32 = 3`
For example:
```
error[E0005]: refutable pattern in local binding: `std::i32::MIN..=1i32` and `3i32..=std::i32::MAX` not covered
--> $DIR/const-pat-non-exaustive-let-new-var.rs:2:9
|
LL | let A = 3;
| ^
| |
| interpreted as a constant pattern, not a new variable
| help: introduce a variable instead: `a_var`
...
LL | const A: i32 = 2;
| ----------------- constant defined here
```
r? @estebank
cc @matthiaskrgr @rpjohnst
hir: Disallow `target_feature` on constants
Fixes#64768.
This PR fixes an ICE when `#[target_feature]` is applied to constants by disallowing this with the same error as when `#[target_feature]` is applied to other places it shouldn't be.
I couldn't see anything in the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2045-target-feature.md) that suggested that `#[target_feature]` should be applicable to constants or any tests that suggested it should, though I might have missed something - if this is desirable in future, it remains possible to remove this error (but for the time being, I think this error is better than an ICE).
I also added some extra cases to the test for other places where `#[target_feature]` should not be permitted.
cc @gnzlbg
Account for tail expressions when pointing at return type
When there's a type mismatch we make an effort to check if it was
caused by a function's return type. This logic now makes sure to
only point at the return type if the error happens in a tail
expression.
Turn `walk_parent_nodes` method into an iterator.
CC #39968, CC #40799.
Remove unused DepTrackingMap
Deletes some related code (MemoizationMap trait, etc.)
I believe this became unused with red/green incremental introduction, but am uncertain.
There's no longer two distinct gcx and tcx lifetimes which made this
necessary (or, at least, the code compiles -- it's possible we got
better at normalizing, but that seems unlikely).
When there's a type mismatch we make an effort to check if it was
caused by a function's return type. This logic now makes sure to
only point at the return type if the error happens in a tail
expression.
Where possible, the error message includes the name of the crate
that brought in the crate with duplicate lang items (which
helps with debugging). This information is passed on from cstore
using the `extern_crate` query.
Rename `*.node` to `*.kind`, and `hair::Pattern*` to `hair::Pat*`
In both `ast::Expr` and `hir::Expr`:
- Rename `Expr.node` to `Expr.kind`.
- Rename `Pat.node` to `Pat.kind`.
- Rename `ImplItem.node` to `ImplItem.kind`.
- Rename `Lit.node` to `Lit.kind`.
- Rename `TraitItem.node` to `TraitItem.kind`.
- Rename `Ty.node` to `Ty.kind`.
- Rename `Stmt.node` to `Stmt.kind`.
- Rename `Item.node` to `Item.kind`.
- Rename `ForeignItem.node` to `ForeignItem.kind`.
- Rename `MetaItem.node` to `MetaItem.kind`.
Also:
- Rename `hair::FieldPattern` to `hair::FieldPat`.
- Rename `hair::PatternKind` to `hair::PatKind`.
- Rename `hair::PatternRange` to `hair::PatRange`.
- Rename `PatternContext` to `PatCtxt`.
- Rename `PatternTypeProjection` to `PatTyProj`.
- Rename `hair::Pattern` to `hair::Pat`.
These two sets of changes are grouped together to aid with merging. The only changes are renamings.
r? @petrochenkov
When the panic handler is run, the existing Handler may be in a weird
state if it was responsible for triggering the panic. By using a freshly
created Handler, we avoid trying to re-entrantly lock a HandlerInner,
which was causing a double panic on ICEs.
