Skip to content
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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants