Skip to content

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

Closed
jroesch opened this issue Jul 1, 2015 · 5 comments
Closed

Comments

@jroesch
Copy link
Member

jroesch commented Jul 1, 2015

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.

@steveklabnik
Copy link
Member

Did you ever investigate further?

@jroesch
Copy link
Member Author

jroesch commented Jul 20, 2015

@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?

@steveklabnik
Copy link
Member

👍

@soltanmm
Copy link

soltanmm commented Jan 6, 2016

@jroesch There's a FIXME comment that references this issue at present. Is that supposed to be there?

@jroesch
Copy link
Member Author

jroesch commented Jan 6, 2016

@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.

leoyvens added a commit to leoyvens/rust that referenced this issue May 12, 2018
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.
bors added a commit that referenced this issue May 12, 2018
…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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants