…=compiler-errors

Make generic const type mismatches not hide trait impls from the trait solver

pulled out of rust-lang#119895

It does improve diagnostics somewhat, but also causes some extraneous diagnostics in potentially misleading order.

The issue was that a const type mismatch, instead of reporting an error, would silently poison the constant, only for that information to be thrown away and the impl to be treated as "not matching". In rust-lang#119895 this would cause ICEs as well as errors on impls stating that the impl needs to exist for itself to be valid.

…=compiler-errors

Make generic const type mismatches not hide trait impls from the trait solver

pulled out of rust-lang#119895

It does improve diagnostics somewhat, but also causes some extraneous diagnostics in potentially misleading order.

The issue was that a const type mismatch, instead of reporting an error, would silently poison the constant, only for that information to be thrown away and the impl to be treated as "not matching". In rust-lang#119895 this would cause ICEs as well as errors on impls stating that the impl needs to exist for itself to be valid.

…=compiler-errors

Make generic const type mismatches not hide trait impls from the trait solver

pulled out of rust-lang#119895

It does improve diagnostics somewhat, but also causes some extraneous diagnostics in potentially misleading order.

The issue was that a const type mismatch, instead of reporting an error, would silently poison the constant, only for that information to be thrown away and the impl to be treated as "not matching". In rust-lang#119895 this would cause ICEs as well as errors on impls stating that the impl needs to exist for itself to be valid.

Rollup merge of rust-lang#120059 - oli-obk:const_arg_type_mismatch, r=compiler-errors

Make generic const type mismatches not hide trait impls from the trait solver

pulled out of rust-lang#119895

It does improve diagnostics somewhat, but also causes some extraneous diagnostics in potentially misleading order.

The issue was that a const type mismatch, instead of reporting an error, would silently poison the constant, only for that information to be thrown away and the impl to be treated as "not matching". In rust-lang#119895 this would cause ICEs as well as errors on impls stating that the impl needs to exist for itself to be valid.

…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#119305 (Add `AsyncFn` family of traits)
 - rust-lang#119389 (Provide more context on recursive `impl` evaluation overflow)
 - rust-lang#119895 (Remove `track_errors` entirely)
 - rust-lang#120230 (Assert that a single scope is passed to `for_scope`)
 - rust-lang#120278 (Remove --fatal-warnings on wasm targets)
 - rust-lang#120292 (coverage: Dismantle `Instrumentor` and flatten span refinement)
 - rust-lang#120315 (On E0308 involving `dyn Trait`, mention trait objects)
 - rust-lang#120317 (pattern_analysis: Let `ctor_sub_tys` return any Iterator they want)
 - rust-lang#120318 (pattern_analysis: Reuse most of the `DeconstructedPat` `Debug` impl)
 - rust-lang#120325 (rustc_data_structures: use either instead of itertools)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#119895 - oli-obk:track_errors_3, r=matthewjasper

Remove `track_errors` entirely

follow up to rust-lang#119869

r? `@matthewjasper`

There are some diagnostic changes adding new diagnostics or not emitting some anymore. We can improve upon that in follow-up work imo.

Remove various `has_errors` or `err_count` uses

follow up to rust-lang#119895

r? `@nnethercote` since you recently did something similar.

There are so many more of these, but I wanted to get a PR out instead of growing the commit list indefinitely. The commits all work on their own and can be reviewed commit by commit.

Rollup merge of rust-lang#120342 - oli-obk:track_errors6, r=nnethercote

Remove various `has_errors` or `err_count` uses

follow up to rust-lang#119895

r? `@nnethercote` since you recently did something similar.

There are so many more of these, but I wanted to get a PR out instead of growing the commit list indefinitely. The commits all work on their own and can be reviewed commit by commit.

Remove various `has_errors` or `err_count` uses

follow up to rust-lang/rust#119895

r? `@nnethercote` since you recently did something similar.

There are so many more of these, but I wanted to get a PR out instead of growing the commit list indefinitely. The commits all work on their own and can be reviewed commit by commit.

Separate collection of crate-local inherent impls from error tracking

rust-lang#119895 changed the return type of the `crate_inherent_impls` query from `CrateInherentImpls` to `Result<CrateInherentImpls, ErrorGuaranteed>` to avoid needing to use the non-parallel-friendly `track_errors()` to track if an error was reporting from within the query... This was mostly fine until rust-lang#121113, which stopped halting compilation when we hit an `Err(ErrorGuaranteed)` in the `crate_inherent_impls` query.

Thus we proceed onwards to typeck, and since a return type of `Result<CrateInherentImpls, ErrorGuaranteed>` means that the query can *either* return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any `Err(ErrorGuaranteed)` return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in rust-lang#127798.

This PR changes the `crate_inherent_impls` query to return `(CrateInherentImpls, Result<(), ErrorGuaranteed>)`, i.e. returning the inherent impls collected *and* whether an error was reported in the query itself. It firewalls the latter part of that query into a new `crate_inherent_impls_validity_check` just for the `ensure()` call.

This fixes rust-lang#127798.

Rollup merge of rust-lang#130764 - compiler-errors:inherent, r=estebank

Separate collection of crate-local inherent impls from error tracking

rust-lang#119895 changed the return type of the `crate_inherent_impls` query from `CrateInherentImpls` to `Result<CrateInherentImpls, ErrorGuaranteed>` to avoid needing to use the non-parallel-friendly `track_errors()` to track if an error was reporting from within the query... This was mostly fine until rust-lang#121113, which stopped halting compilation when we hit an `Err(ErrorGuaranteed)` in the `crate_inherent_impls` query.

Thus we proceed onwards to typeck, and since a return type of `Result<CrateInherentImpls, ErrorGuaranteed>` means that the query can *either* return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any `Err(ErrorGuaranteed)` return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in rust-lang#127798.

This PR changes the `crate_inherent_impls` query to return `(CrateInherentImpls, Result<(), ErrorGuaranteed>)`, i.e. returning the inherent impls collected *and* whether an error was reported in the query itself. It firewalls the latter part of that query into a new `crate_inherent_impls_validity_check` just for the `ensure()` call.

This fixes rust-lang#127798.

Separate collection of crate-local inherent impls from error tracking

rust-lang#119895 changed the return type of the `crate_inherent_impls` query from `CrateInherentImpls` to `Result<CrateInherentImpls, ErrorGuaranteed>` to avoid needing to use the non-parallel-friendly `track_errors()` to track if an error was reporting from within the query... This was mostly fine until rust-lang#121113, which stopped halting compilation when we hit an `Err(ErrorGuaranteed)` in the `crate_inherent_impls` query.

Thus we proceed onwards to typeck, and since a return type of `Result<CrateInherentImpls, ErrorGuaranteed>` means that the query can *either* return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any `Err(ErrorGuaranteed)` return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in rust-lang#127798.

This PR changes the `crate_inherent_impls` query to return `(CrateInherentImpls, Result<(), ErrorGuaranteed>)`, i.e. returning the inherent impls collected *and* whether an error was reported in the query itself. It firewalls the latter part of that query into a new `crate_inherent_impls_validity_check` just for the `ensure()` call.

This fixes rust-lang#127798.