-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove track_errors
entirely
#119895
Remove track_errors
entirely
#119895
Conversation
This comment has been minimized.
This comment has been minimized.
0eb9aef
to
796c54a
Compare
This comment has been minimized.
This comment has been minimized.
796c54a
to
1b73dd4
Compare
1b73dd4
to
6395825
Compare
…=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.
☔ The latest upstream changes (presumably #120242) made this pull request unmergeable. Please resolve the merge conflicts. |
6395825
to
96bcfa5
Compare
96bcfa5
to
db7cd57
Compare
@@ -17,6 +17,272 @@ help: consider further restricting the associated type | |||
LL | Expr: Expression<SqlType=<Col::SqlType as IntoNullable>::Nullable>, <Col as Expression>::SqlType: NotNull, | |||
| +++++++++++++++++++++++++++++++++++++++ | |||
|
|||
error: aborting due to 1 previous error | |||
error[E0277]: the trait bound `<Col as Expression>::SqlType: NotNull` is not satisfied |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know what this is caused by?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@bors r+ |
…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.
follow up to #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.