-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Internal Fulfillment Context assertion tripped, needs more investigation #26721
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Did you ever investigate further? |
@steveklabnik I'm currently rewriting a large chunk of the fulfillment context that I believe will make this a non-issue, but we should probably keep this open for the time being if is okay with you? |
👍 |
@jroesch There's a |
@soltanmm this is references a problem with the current fulfillment context design, where we can't re-use fulfillment contexts because they have no transactional support, this was fixed on my branch refactoring the inference engine. I'm currently trying to rebase this with #30533, still need to touch base with Niko about it though. Was with family for my grandmother's 90th birthday that past couple days, home again and back to work. |
In Copy derive, report all fulfillment erros when present and do not report errors for types tainted with `TyErr`. Also report all fields which are not Copy rather than just the first. Also refactored `fn fully_normalize`, removing the not very useful helper function along with a FIXME to the closed issue rust-lang#26721 that's looks out of context now.
…derive, r=estebank Better error reporting in Copy derive In Copy derive, report all fulfillment erros when present and do not report errors for types tainted with `TyErr`. Also report all fields which are not Copy rather than just the first. Also refactored `fn fully_normalize`, removing the not very useful helper function along with a FIXME to the closed issue #26721 that looks out of context now. Fixes #50480 r? @estebank
I'm not sure if this is a bug or not, needs further investigation. It appears that by reusing the fulfillment_cx here we incur more obligations and later trip an assertion.
The two possibilities I see is:
- normalization is not actually fully happening and we have a bug else where
- we are adding a duplicate bound into the list causing its size to change.
The text was updated successfully, but these errors were encountered: