better ObligationCause for normalization errors in can_type_implement_copy#93714
Conversation
|
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
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.
81b2700 to
6de05ba
Compare
|
r=me with FIXME @bors delegate+ |
|
✌️ @compiler-errors can now approve this pull request |
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 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