Revamp symbol names for impls (and make them deterministic, etc) #32293
Conversation
|
Note that the review is technically only for my comments, not mw's, but of course feel free to comment on those too and I'll patch up any nits or whatever. |
| /// the original crate but also its def-id. This is kind of an | ||
| /// augmented version of a `DefPath` that includes a `DefId`. This is | ||
| /// all sort of ugly but the hope is that inlined items will be going | ||
| /// away soon anyway. |
There was a problem hiding this comment.
We could pass the original id in the trans::inline path just like MIR.
|
LGTM, except for the nits, some of which GitHub is marking as being on an outdated diff. |
| pub struct Foo { x: u32 } | ||
|
|
||
| impl Foo { | ||
| #[rustc_symbol_name] //~ ERROR _ZN5impl13foo3Foo3bar |
|
☔ The latest upstream changes (presumably #32080) made this pull request unmergeable. Please resolve the merge conflicts. |
|
|
||
| #[rustc_symbol_name] //~ ERROR _ZN5basic4main |
There was a problem hiding this comment.
This name and others should end with an 'E' to close the nested name that was started with the 'N'.
There was a problem hiding this comment.
On Sat, Mar 19, 2016 at 04:01:27PM -0700, Michael Woerister wrote:
+#[rustc_symbol_name] //~ ERROR _ZN5basic4main
This name and others should end with an 'E' to close the
nested namethat was started with the 'N'.
The names do end with E. I just left that out of the test because I didn't want to put the hash in there.
|
Looks good to me too. Consolidating path rendering into its own module is a good idea and it's great that we'll be testing symbol names from now on. Looking forward to tinkering with the name mangling scheme. |
nikomatsakis
force-pushed
the
incr-comp-def-path-munging
branch
2 times, most recently
from
3214c33
to
bdfc0b4
Compare
|
Rebased. Some of the poor @michaelwoerister's beautifully clean commit history got a bit messed up (I suspect the individual commits no longer build), but seems to build locally. Not yet finished with |
|
@bors r=eddyb |
|
📌 Commit 8786477 has been approved by |
nikomatsakis
force-pushed
the
incr-comp-def-path-munging
branch
from
8786477
to
09574bd
Compare
|
@bors r- |
Does this just mean removing the comment on the test? If so, I did that in the most recent commit. |
|
@bors r=eddyb |
|
📌 Commit ea70d16 has been approved by |
|
⌛ Testing commit ea70d16 with merge dec92c1... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
@bors r=eddyb |
|
📌 Commit 4eadadf has been approved by |
|
question to @alexcrichton -- do you know if the windows builders have |
nikomatsakis
force-pushed
the
incr-comp-def-path-munging
branch
from
8cfc003
to
726ba66
Compare
|
@bors r=alexcrichton |
|
📌 Commit 726ba66 has been approved by |
|
@bors p=1 |
|
(This PR has been hanging around way too long.) |
|
⌛ Testing commit 726ba66 with merge 07ee0ed... |
|
💔 Test failed - auto-win-gnu-64-nopt-t |
|
@bors r=alexcrichton |
|
📌 Commit 874574d has been approved by |
|
@bors force |
|
⌛ Testing commit 874574d with merge 0f50c0d... |
|
💔 Test failed - auto-win-gnu-64-nopt-t |
|
@bors r=alexcrichton |
|
📌 Commit 1ea93c2 has been approved by |
…xcrichton Revamp symbol names for impls (and make them deterministic, etc) This builds on @michaelwoerister's epic PR #31539 (note that his PR never landed, so I just incorporated it into this one). The main change here is that we remove the "name" from `DefPathData` for impls, since that name is synthetic and not sufficiently predictable for incr comp. However, just doing that would cause bad symbol names since those are based on the `DefPath`. Therefore, I introduce a new mechanism for getting symbol names (and also paths for user display) called `item_path`. This is kind of simplistic for now (based on strings) but I expect to expand it later to support richer types, hopefully generating C++-mangled names that gdb etc can understand. Along the way I cleaned up how we track the path that leads to an extern crate. There is still some cleanup left undone here. Notably, I didn't remove the impl names altogether -- that would probably make sense. I also didn't try to remove the `item_symbols` vector. Mostly I want to unblock my other incr. comp. work. =) r? @eddyb cc @eddyb @alexcrichton @michaelwoerister
This builds on @michaelwoerister's epic PR #31539 (note that his PR never landed, so I just incorporated it into this one). The main change here is that we remove the "name" from
DefPathDatafor impls, since that name is synthetic and not sufficiently predictable for incr comp. However, just doing that would cause bad symbol names since those are based on theDefPath. Therefore, I introduce a new mechanism for getting symbol names (and also paths for user display) calleditem_path. This is kind of simplistic for now (based on strings) but I expect to expand it later to support richer types, hopefully generating C++-mangled names that gdb etc can understand. Along the way I cleaned up how we track the path that leads to an extern crate.There is still some cleanup left undone here. Notably, I didn't remove the impl names altogether -- that would probably make sense. I also didn't try to remove the
item_symbolsvector. Mostly I want to unblock my other incr. comp. work. =)r? @eddyb
cc @eddyb @alexcrichton @michaelwoerister