Be less confident when `dyn` suggestion is not checked for object safety
#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in #116434
r? ```@fmease```
Uplift `TypeVisitableExt` into `rustc_type_ir`
This uplifts `TypeVisitableExt` into `rustc_type_ir` so it can be used in an interner-agnostic way. It also moves some `TypeSuperVisitable` bounds onto `Interner` since we don't expect to support libraries that have types which aren't foldable by default.
This restores a couple of asserts in the canonicalizer code we uplifted, and also makes it so that we can use type-flags-based helpers in the solver code, which I'm interested in uplifting.
r? lcnr
Clarify the lifetimes of allocations returned by the `Allocator` trait
The previous definition (accidentally) disallowed the implementation of stack-based allocators whose memory would become invalid once the lifetime of the allocator type ended.
This also ensures the validity of the following blanket implementation:
```rust
impl<A: Allocator> Allocator for &'_ A {}
```
Additional doc links and explanation of `Wake`.
This is intended to clarify:
* That `Wake` exists and can be used instead of `RawWaker`.
* How to construct a `Waker` when you are looking at `Wake` (which was previously only documented in the example).
Fully stop using the HIR in trait impl checks
At least I hope I found all happy path usages. I'll need to check if I can figure out a way to make queries declare that they don't access the HIR except in error paths
`cargo update`
Run `cargo update`, with some pinning and fixes necessitated by that. This *should* unblock #112865
There's a couple of places where I only pinned a dependency in one location - this seems like a bit of a hack, but better than duplicating the FIXME across all `Cargo.toml` where a dependency is introduced.
cc `@Nilstrieb`
Ignore own item bounds in parent alias types in `for_each_item_bound`
Fixes#120912
I want to get a vibe check on this approach, which is very obviously a hack, but I believe something that is forwards-compatible with a more thorough solution and "good enough for now".
The problem here is that for a really deep rigid associated type, we are now repeatedly considering unrelated item bounds from the parent alias types, meaning we're doing a *lot* of extra work in the MIR inliner for deeply substituted rigid projections.
This feels intimately related to #107614. In that PR, we split *supertrait* bounds (bound which share the same `Self` type as the predicate which is being elaborated) and *implied* bounds (anything that is implied by elaborating the predicate).
The problem here is related to the fact that we don't maintain the split between these two for `item_bounds`. If we did, then when recursing into a parent alias type, we'd want to consider only the bounds that are given by [`PredicateFilter::All`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/astconv/enum.PredicateFilter.html#variant.SelfOnly) **except** those given by [`PredicateFilter::SelfOnly`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/astconv/enum.PredicateFilter.html#variant.SelfOnly).
Do not assemble candidates for default impls
There is no reason (as far as I can tell?) that we should assemble an impl candidate for a default impl. This candidate itself does not prove that the impl holds, and any time that it *does* hold, there will be a more specializing non-default impl that also is assembled.
This is because `default impl<T> Foo for T {}` actually expands to `impl<T> Foo for T where T: Foo {}`. The only way to satisfy that where clause (without coinduction) is via *another* implementation that does hold -- precisely an impl that specializes it.
This should fix the specialization related regressions for #116494. That should lead to one root crate regression that doesn't have to do with specialization, which I think we can regress.
r? lcnr cc ``@rust-lang/types``
cc #31844
Fix incorrect use of `compile_fail`
`compile_fail` should only be used when the code is meant to show what *not* to do. In other words, there should be a fundamental flaw in the code. However, in this case, the example is just incomplete, so we should use `ignore` to avoid confusing readers.
rustdoc: replace `clean::InstantiationParam` with `clean::GenericArg`
Probably better known as `SubstParam` (until #120958 which should've probably renamed it to `InstantiatedParam` but anyways).
It doesn't make any sense to me why it should exist as a separate type. `GenericArg` is exactly what we want here anyways from a semantic perspective. Both have the same size btw.
I also took the liberty of doing some drive-by cleanups.
Check normalized call signature for WF in mir typeck
Unfortunately we don't check that the built-in implementations for `Fn*` traits are actually well-formed in the same way that we do for user-provided impls.
Essentially, when checking a call terminator, we end up with a signature that references an unnormalized `<[closure] as FnOnce<...>>::Output` in its output. That output type, due to the built-in impl, doesn't follow the expected rule that `WF(ty)` implies `WF(normalized(ty))`. We fix this by also checking the normalized signature here.
**See** boxy's detailed and useful explanation comment which explains this in more detail: https://github.com/rust-lang/rust/issues/114936#issuecomment-1710388741Fixes#114936Fixes#118876
r? types
cc ``@BoxyUwU`` ``@lcnr``
There are a couple of places where we call
`inner.emitter.emit_diagnostic` directly rather than going through
`inner.emit_diagnostic`, to guarantee the diagnostic is printed. This
feels dubious to me, particularly the bypassing of `TRACK_DIAGNOSTIC`.
This commit removes those.
- In `print_error_count`, it uses `ForceWarning` instead of `Warning`.
- It removes `DiagCtxtInner::failure_note`, because it only has three
uses and direct use of `emit_diagnostic` is consistent with other
similar locations.
- It removes `force_print_diagnostic`, and adds `struct_failure_note`,
and updates `print_query_stack` accordingly, which makes it more
normal. That location doesn't seem to need forced printing anyway.
`compile_fail` should only be used when the code is meant to show
what *not* to do. In other words, there should be a fundamental flaw
in the code. However, in this case, the example is just incomplete,
so we should use `ignore` to avoid confusing readers.
RustWrapper: adapt for coverage mapping API changes
There've been a number of changes to the coverage mapping API today, but the end result is that specifying the MCDC parameters is now optional (they've been moved to the end of the argument list and now default to `std::monostate`).
`@rustbot` label: +llvm-main
r? `@durin42`
coverage: Simplify some parts of the coverage span refiner
This is another incremental step on my quest to dismantle the coverage span refiner into something more understandable and maintainable.
The biggest change here is splitting up `CoverageSpan` into several more specific structs. Doing so reveals that most of the places that were using that struct only need a subset of its fields and methods.
We can also get rid of separate tracking of `curr_original_span` and `prev_original_span`, by observing that `curr.span` never actually needs to be mutated, and that we can store `prev_original_span` directly in the dedicated struct for `prev`.
`@rustbot` label +A-code-coverage
match lowering: simplify block creation
Match lowering was doing complicated things with block creation. As far as I can tell it was trying to avoid creating unneeded blocks, but of the three places that start out with `otherwise = &mut None`, two of them called `otherwise.unwrap_or_else(|| self.cfg.start_new_block())` anyway. As far as I can tell the only place where this PR makes a difference is in `lower_match_tree`, which did indeed sometimes avoid creating the unreachable final block + FakeRead. Unless this is important I propose we do the naive thing instead.
I have not checked all the graph isomorphisms by hand, but at a glance the test diff looks sensible.
r? `@matthewjasper`
modify alias-relate to also normalize ambiguous opaques
allows a bunch of further cleanups and generally simplifies the type system. To handle https://github.com/rust-lang/trait-system-refactor-initiative/issues/8 we'll have to add a some additional complexity to the `(Alias, Infer)` branches in alias-relate, so removing the opaque type special case here is really valuable.
It does worsen `deduce_closure_signature` and friends even more as they now receive an inference variable which is only constrained via an `AliasRelate` goal. These probably have to look into alias relate goals somehow. Leaving that for a future PR as this is something we'll have to tackle regardless.
r? `@compiler-errors`
Update to LLVM 18
LLVM 18 final is planned to be released on Mar 5th. Rust 1.78 is planned to be released on May 2nd.
Tested images: dist-x86_64-linux, dist-s390x-linux, dist-aarch64-linux, dist-riscv64-linux, dist-loongarch64-linux, dist-x86_64-freebsd, dist-x86_64-illumos, dist-x86_64-musl, x86_64-linux-integration, test-various, armhf-gnu, i686-msvc, x86_64-msvc, i686-mingw, x86_64-mingw, x86_64-apple-1, x86_64-apple-2, dist-aarch64-apple
r? `@ghost`
If we only check for duplicate spans when `prev` is unmodified, we reduce the
number of situations that `update_pending_dups` needs to handle.
This could potentially change the coverage spans we produce in some unknown
corner cases, but none of our current coverage tests indicate any change.
