Remove `track_errors` entirely by oli-obk · Pull Request #119895 · rust-lang/rust

oli-obk · 2024-01-12T16:16:51Z

follow up to #119869

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

compiler/rustc_infer/src/infer/relate/combine.rs

compiler/rustc_hir_analysis/src/collect/type_of/opaque.rs

…=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.

bors · 2024-01-22T21:44:15Z

☔ The latest upstream changes (presumably #120242) made this pull request unmergeable. Please resolve the merge conflicts.

compiler/rustc_middle/src/query/mod.rs

matthewjasper · 2024-01-24T10:26:14Z

tests/ui/associated-types/issue-38821.stderr

   |                                                                       +++++++++++++++++++++++++++++++++++++++

-error: aborting due to 1 previous error
+error[E0277]: the trait bound `<Col as Expression>::SqlType: NotNull` is not satisfied


Do we know what this is caused by?

I think it's just lots of occurrences within the bodies of the Debug and Clone impls. Before this PR we didn't continue to the bodies due to the previous errors. All the errors are deduplicated, so this isn't user-visibble

matthewjasper · 2024-01-24T17:20:06Z

@bors r+

bors · 2024-01-24T17:20:09Z

📌 Commit cc34dc2 has been approved by matthewjasper

It is now in the queue for this repository.

…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.

rustbot assigned matthewjasper Jan 12, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 12, 2024

oli-obk commented Jan 12, 2024

View reviewed changes

compiler/rustc_infer/src/infer/relate/combine.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

oli-obk force-pushed the track_errors_3 branch from 0eb9aef to 796c54a Compare January 12, 2024 16:28

This comment has been minimized.

Sign in to view

nnethercote reviewed Jan 16, 2024

View reviewed changes

compiler/rustc_hir_analysis/src/collect/type_of/opaque.rs Outdated Show resolved Hide resolved

oli-obk force-pushed the track_errors_3 branch from 796c54a to 1b73dd4 Compare January 17, 2024 14:56

This was referenced Jan 17, 2024

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

Merged

Fix error counting #119986

Merged

oli-obk force-pushed the track_errors_3 branch from 1b73dd4 to 6395825 Compare January 19, 2024 15:05

oli-obk force-pushed the track_errors_3 branch from 6395825 to 96bcfa5 Compare January 23, 2024 15:05

Remove track_errors entirely

db7cd57

oli-obk force-pushed the track_errors_3 branch from 96bcfa5 to db7cd57 Compare January 23, 2024 15:23

oli-obk marked this pull request as ready for review January 23, 2024 15:24

matthewjasper reviewed Jan 24, 2024

View reviewed changes

Correctly explain ensure_forwards_result_if_red

cc34dc2

rustbot added the A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) label Jan 24, 2024

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 24, 2024

matthiaskrgr mentioned this pull request Jan 25, 2024

Rollup of 10 pull requests #120335

Merged

bors merged commit 0c45e3c into rust-lang:master Jan 25, 2024

rustbot added this to the 1.77.0 milestone Jan 25, 2024

oli-obk deleted the track_errors_3 branch January 25, 2024 11:36

oli-obk mentioned this pull request Jan 25, 2024

Remove various has_errors or err_count uses #120342

Merged

matthiaskrgr mentioned this pull request Jan 25, 2024

ICE: missing value for assoc item in impl #120343

Closed

compiler-errors mentioned this pull request Sep 23, 2024

Separate collection of crate-local inherent impls from error tracking #130764

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Remove `track_errors` entirely#119895

Remove `track_errors` entirely#119895
bors merged 2 commits intorust-lang:masterfrom
oli-obk:track_errors_3

oli-obk commented Jan 12, 2024 •

edited

Loading

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

bors commented Jan 22, 2024

Uh oh!

Uh oh!

matthewjasper Jan 24, 2024

Uh oh!

oli-obk Jan 24, 2024

Uh oh!

matthewjasper commented Jan 24, 2024

Uh oh!

bors commented Jan 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

oli-obk commented Jan 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

bors commented Jan 22, 2024

Uh oh!

Uh oh!

matthewjasper Jan 24, 2024

Choose a reason for hiding this comment

Uh oh!

oli-obk Jan 24, 2024

Choose a reason for hiding this comment

Uh oh!

matthewjasper commented Jan 24, 2024

Uh oh!

bors commented Jan 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

oli-obk commented Jan 12, 2024 •

edited

Loading