Deeply normalize TypeTrace when reporting type error in new solver#131756
Deeply normalize TypeTrace when reporting type error in new solver#131756bors merged 2 commits intorust-lang:masterfrom
TypeTrace when reporting type error in new solver#131756Conversation
rustbot
added
S-waiting-on-review
| cause: &ObligationCause<'tcx>, | ||
| secondary_span: Option<(Span, Cow<'static, str>)>, | ||
| mut values: Option<ValuePairs<'tcx>>, | ||
| mut values: Option<(ValuePairs<'tcx>, ty::ParamEnv<'tcx>)>, |
There was a problem hiding this comment.
i feel like the param env should always be required together with the cause 🤔
looking at the uses of note_type_err I feel like this should be a straightforward change
There was a problem hiding this comment.
Well, so the param-env of this ValuePairs is conceptually distinct from param-env of the TypeError that may be emitted, since (well, in the future perhaps) the TypeError may have instantiated binders in scope as well.
So like, imagine a type error between1 for<T: Foo<Assoc = i32>> fn(<T as Foo>::Assoc) and fn(u32). The valuepairs will contain the outer types, but the type error will likely be a TypeError::Sorts mismatch between <!T as Foo>::Assoc2 (w/ the param-env augmented with !T: Foo<Assoc = i32>) and u32. I think that other param-env may ned to be tracked separately.
I think we could still pass in the "outermost" param-env as a separate arg, but it seems kinda a waste since that param-env really is tightly associated only w the ValuePairs...
thoughts?
Footnotes
There was a problem hiding this comment.
I guess you're right 😢 😁
vibeck: ParamEnvAnd instead of a tuple here?
anyways, r=me
|
r=me after nit |
I intend to fix this in the near future, can you add a |
|
☔ The latest upstream changes (presumably #131797) made this pull request unmergeable. Please resolve the merge conflicts. |
compiler-errors
force-pushed
the
deeply-normalize-type-err
branch
from
405013e to
693f2bb
Compare
|
☔ The latest upstream changes (presumably #131948) made this pull request unmergeable. Please resolve the merge conflicts. |
compiler-errors
force-pushed
the
deeply-normalize-type-err
branch
from
693f2bb to
4217b87
Compare
|
@bors r=lcnr |
bors
added
S-waiting-on-bors
Rollup of 10 pull requests Successful merges: - rust-lang#130225 (Rename Receiver -> LegacyReceiver) - rust-lang#131169 (Fix `target_vendor` in QNX Neutrino targets) - rust-lang#131623 (misc cleanups) - rust-lang#131756 (Deeply normalize `TypeTrace` when reporting type error in new solver) - rust-lang#131898 (minor `*dyn` cast cleanup) - rust-lang#131909 (Prevent overflowing enum cast from ICEing) - rust-lang#131930 (Don't allow test revisions that conflict with built in cfgs) - rust-lang#131956 (coverage: Pass coverage mappings to LLVM as separate structs) - rust-lang#132076 (HashStable for rustc_feature::Features: stop hashing compile-time constant) - rust-lang#132088 (Print safety correctly in extern static items) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#131756 - compiler-errors:deeply-normalize-type-err, r=lcnr Deeply normalize `TypeTrace` when reporting type error in new solver Normalize the values that come from the `TypeTrace` for various type mismatches. Side-note: We can't normalize the `TypeError` itself bc it may come from instantiated binders, so it may reference values from within the probe... r? lcnr
4 participants
Normalize the values that come from the
TypeTracefor various type mismatches.Side-note: We can't normalize the
TypeErroritself bc it may come from instantiated binders, so it may reference values from within the probe...r? lcnr