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.
This test started failing on LLVM 18 after change
61118ffd04aa6d1f9ee92daae4deb28bd975d4ab. As far as I can tell, it's
just good fortune that LLVM is able to sniff out the new noalias here,
and it's correct.
Rollup of 10 pull requests
Successful merges:
- #120696 (Properly handle `async` block and `async fn` in `if` exprs without `else`)
- #120751 (Provide more suggestions on invalid equality where bounds)
- #120802 (Bail out of drop elaboration when encountering error types)
- #120967 (docs: mention round-to-even in precision formatting)
- #120973 (allow static_mut_ref in some tests that specifically test mutable statics)
- #120974 (llvm-wrapper: adapt for LLVM API change: Add support for EXPORTAS name types)
- #120986 (iterator.rs: remove "Basic usage" text)
- #120987 (remove redundant logic)
- #120988 (fix comment)
- #120995 (PassWrapper: adapt for llvm/llvm-project@93cdd1b5cf)
r? `@ghost`
`@rustbot` modify labels: rollup
docs: mention round-to-even in precision formatting
_Note_: Not quite sure exactly how to format this documentation.
Mentions round-to-even usage in precision formatting. (should this also be mentioned in `f64::round`?)
From https://github.com/rust-lang/rust/issues/70336
