better ObligationCause for normalization errors in can_type_implement_copy
#93714
Conversation
rustbot
added
the
T-compiler
|
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
| // If the ADT has substs, point to the cause we are given. | ||
| // If it does not, then this field probably doesn't normalize | ||
| // to begin with, and point to the bad field. | ||
| let cause = if field | ||
| .ty(tcx, traits::InternalSubsts::identity_for_item(tcx, adt.did)) | ||
| .has_param_types_or_consts() | ||
| { | ||
| cause.clone() | ||
| } else { | ||
| ObligationCause::dummy_with_span(span) | ||
| }; |
There was a problem hiding this comment.
This is...weird. If you don't do this, what changes?
There was a problem hiding this comment.
Some test starts pointing at a derive(Copy) saying that the type doesn't implement a trait, instead of the struct field.
Not at my computer, but it's some test that contains <u32 as Iterator>::Item in a struct that derives Copy.
There was a problem hiding this comment.
I've split out this hack into its own commit -- see aa4d68a for the regression in spans in issue-50480 (i.e. without this code).
There's probably something I don't understand about the ordering of the impl Copy correctness check and whatever check (wf?) that raises an error that the struct field <i32 as Iterator>::Item is invalid. Perhaps I can fix this in a better way than I am doing right now.
There was a problem hiding this comment.
Ugh, I see that this does fix a Span, but it still feels wrong to me. Kind of signals that this isn't the best diff. Anyways, can you just add a FIXME.
compiler-errors
force-pushed
the
can-type-impl-copy-error-span
branch
from
81b2700 to
6de05ba
Compare
|
r=me with FIXME @bors delegate+ |
|
✌️ @compiler-errors can now approve this pull request |
compiler-errors
force-pushed
the
can-type-impl-copy-error-span
branch
from
6de05ba to
ee98dc8
Compare
|
CI is broken because crates.io API is having troubles. Will r= later. |
|
@bors r=jackh726 |
|
📌 Commit ee98dc8 has been approved by |
bors
added
S-waiting-on-bors
|
@bors retry crates.io is still sad |
|
er, maybe just need to r+ again actually @bors r=jackh726 |
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit ee98dc8 has been approved by |
…error-span, r=jackh726 better ObligationCause for normalization errors in `can_type_implement_copy` Some logic is needed so we can point to the field when given totally nonsense types like `struct Foo(<u32 as Iterator>::Item);` Fixes rust-lang#93687
…error-span, r=jackh726 better ObligationCause for normalization errors in `can_type_implement_copy` Some logic is needed so we can point to the field when given totally nonsense types like `struct Foo(<u32 as Iterator>::Item);` Fixes rust-lang#93687
Rollup of 9 pull requests Successful merges: - rust-lang#91795 (resolve/metadata: Stop encoding macros as reexports) - rust-lang#93714 (better ObligationCause for normalization errors in `can_type_implement_copy`) - rust-lang#94175 (Improve `--check-cfg` implementation) - rust-lang#94212 (Stop manually SIMDing in `swap_nonoverlapping`) - rust-lang#94242 (properly handle fat pointers to uninhabitable types) - rust-lang#94308 (Normalize main return type during mono item collection & codegen) - rust-lang#94315 (update auto trait lint for `PhantomData`) - rust-lang#94316 (Improve string literal unescaping) - rust-lang#94327 (Avoid emitting full macro body into JSON errors) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…error-span, r=jackh726 better ObligationCause for normalization errors in `can_type_implement_copy` Some logic is needed so we can point to the field when given totally nonsense types like `struct Foo(<u32 as Iterator>::Item);` Fixes rust-lang#93687
Some logic is needed so we can point to the field when given totally nonsense types like
struct Foo(<u32 as Iterator>::Item);Fixes #93687