Add initial implementation of HIR-based WF checking for diagnostics#83898
Add initial implementation of HIR-based WF checking for diagnostics#83898bors merged 1 commit intorust-lang:masterfrom
Conversation
|
r? @varkor (rust-highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
cc @rust-lang/wg-traits: Does Chalk have a way of getting the obligation first passed to TraitEngine::register_predicate_obligation?
There was a problem hiding this comment.
Well, does Chalk? No. Chalk only takes a goal and produces an answer. Does the chalk_fulfill code? I'm not sure, I'll have to go back through this.
I imagine that the code here is most correct. The rustc trait solver will register predicates as it tries to solve a predicate, whereas Chalk won't, it just gives back an answer.
There was a problem hiding this comment.
Yeah, chalk sort of only has a notion of root obligation, at least as presently designed.
There was a problem hiding this comment.
I'm not too concerned because I already fully expect to have to rework a lot of things when we try to land chalk :)
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
8eb793d to
962fccd
Compare
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
|
⌛ Trying commit 962fccd92d7b05b813e61caba12756a6c1ccca26 with merge 8a8a6e6b205d7dc020125389bc03483f80fee94c... |
|
☀️ Try build successful - checks-actions |
|
Queued 8a8a6e6b205d7dc020125389bc03483f80fee94c with parent 5a7a0ac, future comparison URL. |
|
Finished benchmarking try commit (8a8a6e6b205d7dc020125389bc03483f80fee94c): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
|
I'm a little short on time for larger reviews at the moment, so I'm going to reassign to avoid delay. r? @estebank |
This comment has been minimized.
This comment has been minimized.
0fe07ab to
c0b8604
Compare
|
☔ The latest upstream changes (presumably #86993) made this pull request unmergeable. Please resolve the merge conflicts. |
c0b8604 to
d07f0a7
Compare
|
@Aaron1011 sorry for the delays. Looking at this PR now. |
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
|
⌛ Trying commit d07f0a702d7c37c08988d06ddda241720f0cad76 with merge 2b90040103d3c924f06ba922b016ccdd6e47f4b9... |
estebank
left a comment
There was a problem hiding this comment.
r=me after addressing nitpicks
compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I'm not too concerned because I already fully expect to have to rework a lot of things when we try to land chalk :)
|
☀️ Try build successful - checks-actions |
|
Queued 2b90040103d3c924f06ba922b016ccdd6e47f4b9 with parent 2119976, future comparison URL. |
|
Finished benchmarking try commit (2b90040103d3c924f06ba922b016ccdd6e47f4b9): comparison url. Summary: This benchmark run did not return any significant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. @bors rollup=never |
During well-formed checking, we walk through all types 'nested' in generic arguments. For example, WF-checking `Option<MyStruct<u8>>` will cause us to check `MyStruct<u8>` and `u8`. However, this is done on a `rustc_middle::ty::Ty`, which has no span information. As a result, any errors that occur will have a very general span (e.g. the definintion of an associated item). This becomes a problem when macros are involved. In general, an associated type like `type MyType = Option<MyStruct<u8>>;` may have completely different spans for each nested type in the HIR. Using the span of the entire associated item might end up pointing to a macro invocation, even though a user-provided span is available in one of the nested types. This PR adds a framework for HIR-based well formed checking. This check is only run during error reporting, and is used to obtain a more precise span for an existing error. This is accomplished by individually checking each 'nested' type in the HIR for the type, allowing us to find the most-specific type (and span) that produces a given error. The majority of the changes are to the error-reporting code. However, some of the general trait code is modified to pass through more information. Since this has no soundness implications, I've implemented a minimal version to begin with, which can be extended over time. In particular, this only works for HIR items with a corresponding `DefId` (e.g. it will not work for WF-checking performed within function bodies).
d07f0a7 to
a765333
Compare
|
@bors r=estebank |
|
📌 Commit a765333 has been approved by |
|
☀️ Test successful - checks-actions |
During well-formed checking, we walk through all types 'nested' in
generic arguments. For example, WF-checking
Option<MyStruct<u8>>will cause us to check
MyStruct<u8>andu8. However, this is doneon a
rustc_middle::ty::Ty, which has no span information. As a result,any errors that occur will have a very general span (e.g. the
definintion of an associated item).
This becomes a problem when macros are involved. In general, an
associated type like
type MyType = Option<MyStruct<u8>>;mayhave completely different spans for each nested type in the HIR. Using
the span of the entire associated item might end up pointing to a macro
invocation, even though a user-provided span is available in one of the
nested types.
This PR adds a framework for HIR-based well formed checking. This check
is only run during error reporting, and is used to obtain a more precise
span for an existing error. This is accomplished by individually
checking each 'nested' type in the HIR for the type, allowing us to
find the most-specific type (and span) that produces a given error.
The majority of the changes are to the error-reporting code. However,
some of the general trait code is modified to pass through more
information.
Since this has no soundness implications, I've implemented a minimal
version to begin with, which can be extended over time. In particular,
this only works for HIR items with a corresponding
DefId(e.g. it willnot work for WF-checking performed within function bodies).