Skip to content

Dangling item id in partial specializations #210

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

Conversation

fitzgen
Copy link
Member

@fitzgen fitzgen commented Nov 4, 2016

See individual commit messages for details.

r? @emilio

This adds a temporary binding for the newly allocated id so that we can
use it in conditional breakpoints when debugging dangling `ItemId`
references. I believe that we will want the ability to set conditional
breakpoints in this method every single time we end up debugging
dangling references, so it is worth landing in master.
@emilio
Copy link
Contributor

emilio commented Nov 4, 2016

Looks good to me, just one question. If you could add a test for this, that'd be neat.

r=me, ideally with test (I'd look into specifying something like --whitelist-type dummy so we need to scan the items or something)

@emilio
Copy link
Contributor

emilio commented Nov 4, 2016

@bors-servo delegate+

@bors-servo
Copy link

✌️ @fitzgen can now approve this pull request

// this type, so if we pass `with_id` as the parent, it is
// potentially a dangling reference. Instead, use the canonical
// template declaration as the parent. It is already parsed and
// has a known-resolvable `ItemId`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this comment is not as accurate as it should. This ends up unused if we peek the early return in line 555 (the one with the error! thing, it's not about finding other type that is the same.

…ldren

The `with_id` id will potentially end up unused if we find we already
have an item (with its own distinct `ItemId`) for the type, so if we
pass `with_id` as the parent id when parsing children it is potentially
a dangling reference. Instead, use the canonical template declaration as
the parent. It is already parsed and has a known-resolvable `ItemId`.
@fitzgen fitzgen force-pushed the dangling-item-id-in-partial-specializations branch from abb3cd5 to d14b602 Compare November 4, 2016 21:16
@fitzgen
Copy link
Member Author

fitzgen commented Nov 4, 2016

@bors-servo r=emilio

I tried creating a test case, but couldn't build one that triggered this behavior :-/

@bors-servo
Copy link

📌 Commit d14b602 has been approved by emilio

@bors-servo
Copy link

⌛ Testing commit d14b602 with merge f498903...

bors-servo pushed a commit that referenced this pull request Nov 4, 2016
…ons, r=emilio

Dangling item id in partial specializations

See individual commit messages for details.

r? @emilio
@bors-servo
Copy link

☀️ Test successful - status-travis

@bors-servo bors-servo merged commit d14b602 into rust-lang:master Nov 4, 2016
@fitzgen fitzgen deleted the dangling-item-id-in-partial-specializations branch November 4, 2016 21:31
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

Successfully merging this pull request may close these issues.

4 participants