Remove dead diagnostic structs.
One of these has a "FIXME(autodiff): I should get used somewhere" comment, but I figure YAGNI applies and it's so small that reinstating it if necessary would be trivial.
r? @Kivooeo
One of these has a "FIXME(autodiff): I should get used somewhere"
comment, but I figure YAGNI applies and it's so small that reinstating
it if necessary would be trivial.
Post-attribute ports cleanup pt. 1 (again)
This is a re-implementation of most (but not all) of https://github.com/rust-lang/rust/pull/154808
The code is the same as in that PR, other than a few changes, I'll leave comments where I changed things.
I did re-implement most of the commits rather than cherry-picking, so it's probably good to check the entire diff regardless
r? @jdonszelmann
Small refactor of `arena_cache` query values
Query modifier `arena_cache` automatically allocates only `Some` variant of query's value of type `Option<&'tcx T>`, so `mir_callgraph_cyclic` should've been doing it from the beginning. The same could be said for any `Result<&'tcx T, ErrorGuaranteed>` as `ErrorGuaranteed` is a zero sized type, but that requires adding a new `ArenaCached` implementation.
Normalize individual predicate of `InstantiatedPredicates` inside `predicates_for_generics`
This is a cleanup to better land rust-lang/rust#155083. It allows us to wrap individual clause in `Unnormalized` wrapper. See [this comment](https://github.com/rust-lang/rust/pull/155083#discussion_r3072219035)
Besides that, this PR also adds missing normalization in some cases.
r? @lcnr
Use closures more consistently in `dep_graph.rs`.
This file has several methods that take a `FnOnce() -> R` closure:
- `DepGraph::with_ignore`
- `DepGraph::with_query_deserialization`
- `DepGraph::with_anon_task`
- `DepGraphData::with_anon_task_inner`
It also has two methods that take a faux closure via an `A` argument and a `fn(TyCtxt<'tcx>, A) -> R` argument:
- DepGraph::with_task
- DepGraphData::with_task
The rationale is that the faux closure exercises tight control over what state they have access to. This seems silly when (a) they are passed a `TyCtxt`, and (b) when similar nearby functions take real closures. And they are more awkward to use, e.g. requiring multiple arguments to be gathered into a tuple. This commit changes the faux closures to real closures.
r? @Zalathar
delegation: support proper interaction of user-specified args and impl Traits
This PR supports usages of user-specified args with impl Traits. When there are user-specified args in child we still need to generate synthetic generic params and use them during signature inheritance:
```rust
fn foo<T, const N: usize>(f: impl FnOnce()) {}
reuse foo::<String, 123> as bar;
//desugaring
fn bar<TSynth: impl FnOnce()>(f: _) {
foo::<String, 123>(f)
}
```
When inheriting predicates we process impl Trait ones, so we need generic params to instantiate them. Other approach may involve not generating synthetic generic params and try to filter out those predicates, but fairly generating synthetic params seems more consistent?.
Fixesrust-lang/rust#154780, part of rust-lang/rust#118212.
r? @petrochenkov
Simplify `try_load_from_disk_fn`.
`try_load_from_disk_fn` has a single call site. We can move some of the stuff within it to its single call site, which simplifies it, and also results in all of the query profiling code ending up in the same module. Details in individual commits.
r? @Zalathar
From `plumbing.rs` to `execution.rs`, which is where most of the other
query profiling occurs. It also avoids eliminates some fn parameters.
This means the `provided_to_erased` call in `try_from_load_disk_fn` is
now included in the profiling when previously it wasn't. This is
good because `provided_to_erased` is included in other profiling calls
(e.g. calls to `invoke_provider_fn`).
It doesn't need to be in there, it can instead be at the single call
site. Removing it eliminates one parameter, makes `define_queries!`
smaller (which is always good), and also enables the next commit which
tidies up profiling.
This commit also changes how `value` and `verify` are initialized,
because I don't like the current way of doing it after the declaration.
delegation: fix cycles during delayed lowering
This PR forces lowering of delayed owners after `hir_crate_items`, as some diagnostics use `hir_crate_items` which results in query cycle which is then hangs calling `def_path_str` again and again. Fixesrust-lang/rust#154169. Part of rust-lang/rust#118212.
r? @petrochenkov
Move `maybe_loop_headers` out of `rustc_middle`.
`rustc_middle` is enormous and it's always good to move things out of it where possible. `maybe_loop_headers` is easy to move because it has a single use in `jump_threading.rs`.
r? @WaffleLapkin
`rustc_middle` is enormous and it's always good to move things out of it
where possible. `maybe_loop_headers` is easy to move because it has a
single use in `jump_threading.rs`.
Post-attribute ports cleanup pt. 1
r? @jdonszelmann
This cleans up some checks I could find were for non-parsed attributes, and works towards removing BUILTIN_ATTRIBUTES
All commits do one thing and every commit passes tests, so best reviewed commit by commit
`ty::Alias` refactor
This PR changes the following alias-related types from this:
```rust
pub enum AliasTyKind {
Projection,
Inherent,
Opaque,
Free,
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub def_id: I::DefId,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTyKind, AliasTy<I>),
}
```
Into this:
```rust
pub enum AliasTyKind<I: Interner> {
Projection { def_id: I::DefId },
Inherent { def_id: I::DefId },
Opaque { def_id: I::DefId },
Free { def_id: I::DefId },
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub kind: AliasTyKind<I>,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTy<I>),
}
```
... and then does a thousand other changes to accommodate for this change everywhere.
This brings us closer to being able to have `AliasTyKind`s which don't require a `DefId` (and thus can be more easily created, etc). Although notably we depend on both `AliasTyKind -> DefId` and `DefId -> AliasTyKind` conversions in a bunch of places still.
r? lcnr
----
A lot of these changes were done either by search & replace (via `ast-grep`) or on auto pilot, so I'm not quite sure I didn't mess up somewhere, but at least tests pass...
Add `#[track_caller]` to some functions which can panic b/c of the
caller's wrong index (this helped me debug some mistakes I did while
refactoring `ty::Alias`)
Because the things in this module aren't MIR and don't use anything
from `rustc_middle::mir`. Also, modules that use `mono` often don't use
anything else from `rustc_middle::mir`.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#153440 (Various LTO cleanups)
- rust-lang/rust#151899 (Constify fold, reduce and last for iterator)
- rust-lang/rust#154561 (Suggest similar keyword when visibility is not followed by an item)
- rust-lang/rust#154657 (Fix pattern assignment suggestions for uninitialized bindings)
- rust-lang/rust#154717 (Fix ICE in unsafe binder discriminant helpers)
- rust-lang/rust#154722 (fix(lints): Improve `ill_formed_attribute_input` with better help message)
- rust-lang/rust#154777 (`#[cfg]`: suggest alternative `target_` name when the value does not match)
- rust-lang/rust#154849 (Promote `char::is_case_ignorable` from perma-unstable to unstable)
- rust-lang/rust#154850 (ast_validation: scalable vectors okay for rustdoc)
Fix ICE in unsafe binder discriminant helpers
Forward discriminant-related helpers through `ty::UnsafeBinder` to the erased inner type, matching the existing layout behavior.
Tracking issue: rust-lang/rust#130516Closesrust-lang/rust#154424
Remove `Clone` impl for `StableHashingContext`.
`HashStable::hash_stable` takes a `&mut Hcx`. In contrast, `ToStableHashKey::to_stable_hash_key` takes a `&Hcx`. But there are some places where the latter calls the former, and due to the mismatch a `clone` call is required to get a mutable `StableHashingContext`.
This commit changes `to_stable_hash_key` to instead take a `&mut Hcx`. This eliminates the mismatch, the need for the clones, and the need for the `Clone` impls.
r? @fee1-dead
Remove `DepGraphData::dep_node_debug`.
This hashmap was added in rust-lang/rust#42625 and is used for debug-only printing. If a key isn't recoverable, `DepNode::construct` will create a string for it (using `DepNodeKey::to_debug_str`) and insert the string in the hashmap, but only if (a) it's a debug build, and (b) `-Zincremental-info` or `-Zquery-dep-graph` is specified. ("Recoverable" here means the fingerprint style is `KeyFingerPrintStyle::Opaque`.)
`DepNode::fmt` will then use this string to produce output showing the key itself, and not just its fingerprint.
All this code is debug-only. Some of it is guarded with `#[cfg(debug_assertions)]`, but some is not.
However, the `tcx.def_path_debug_str()` path in `DepNode::fmt` seems to be unreachable. Because it's debug-only it can't be used by normal users and so must only be there for rustc devs. But even in a debug build I was unable to trigger that path. I tried changing it to a panic and ran the full test suite without problem, and then I tried various flag combinations and scenarios also without hitting it. The `-Zincremental-info` condition doesn't make sense because that only prints high-level info about queries, not individual keys. So the path is either unreachable, or so hard to reach that it's not providing any actual value.
This commit removes all this code.
r? @cjgillot
various fixes for scalable vectors
These are a handful of patches fixing bugs with the current `#[rustc_scalable_vector]` infrastructure so that we can upstream the intrinsics to stdarch:
1. Instead of just using regular struct lowering for tuples of scalable vectors, which results in an incorrect ABI (e.g. returning indirectly), we change to using `BackendRepr::ScalableVector` which will lower to the correct type and be passed in registers.
2. Clang changed from representing tuples of scalable vectors as structs rather than as wide vectors (that is, scalable vector types where the `N` part of the `<vscale x N x ty>` type was multiplied by the number of vectors). rustc mirrored this in the initial implementation of scalable vectors that didn't land.
When our early patches used the wide vector representation, our intrinsic patches used the legacy `llvm.aarch64.sve.tuple.{create,get,set}{2,3,4}` intrinsics for creating these tuples/getting/setting the vectors, which were only supported due to LLVM's `AutoUpgrade` pass converting these intrinsics into `llvm.vector.insert`. `AutoUpgrade` only supports these legacy intrinsics with the wide vector representation.
With the current struct representation, Clang has special handling in codegen for generating `insertvalue`/`extractvalue` instructions for these operations, which must be replicated by rustc's codegen for our intrinsics to use.
We add a new `core::intrinsics::scalable` module (never intended to be stable, just used by the stdarch intrinsics, gated by `core_intrinsics`) and add new intrinsics which rustc lowers to the appropriate `insertvalue`/`extractvalue` instructions.
3. Add generation of debuginfo for scalable vectors, following the DWARF that Clang generates.
4. Some intrinsics need something like `simd_cast`, which will work for scalable vectors too, so this implements a new `sve_cast` intrinsic that uses the same internals as `simd_cast`. This seemed better than permitting scalable vectors to be used with the `simd_*` intrinsics more generally as I can't guarantee this would work for all of them.
This is a relatively large patch but most of it is tests, and each commit should be relatively standalone. It's a little bit easier to upstream them together to avoid needing to stack them. It's possible that some more compiler fixes will be forthcoming but it's looking like this might be all at the moment.
Depends on rust-lang/rust#153653
r? @workingjubilee (discussed on Zulip)
Jacob Pratt