-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal Fulfillment Context assertion tripped, needs more investigation #26721
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: