DXR clang indexer does not handle multiple function/variable/etc declarations from a single macro call about dxr HOT 3 CLOSED

I've experimented with some success with breaking the post-processing into two phases, where the functions/macros/types/variables tables built from a first scan of the csv files, and the _decldef tables built from a second scan of the csv files, and omitting the update_decldef step. We'd need to do something similar for the _refs tables, but first we'd need to teach the clang plugin to output the qualname for 'ref' csv rows.

from dxr.

Relying on the qualname being unique might not be such a good idea right
now. For one thing, static global variables are going to cause
collisions. Think of having "static int foo;" in two different translation
units. This could be solved by mangling the qualname for such variables,
perhaps by appending "::" to them or something along
those lines.

There's also the case where you're building multiple binaries and each one
contains "extern int foo = 0;" in separate files. These are separate
variables but they share the same qualname. Unless we add support for
grabbing information from the link phase it would be pretty hard to
distinguish these by qualname alone.

There's also the possibility of local variables that are shadowed:
void foo()
{
int bar; // qualname is foo()::bar
{
int bar; // qualname is also foo()::bar ?
}
}

I think we may want to add qualname to the existing unique key but I seem
to recall that I ran into issues when trying that. When you have
templates, the name you get back depends on whether the template had been
instantiated or not. So you'd get Foo for the definition and then
Foo or Foo or something for the reference. Since these don't
match you'd end up with a lot of places where you couldn't find the entity
that was referenced. You'd have to find a way to get Foo from these
references. But you also have to watch out for the case where there is an
explicit specialization for Foo since in that case you do want to
stay with Foo and not have Foo. Templates are complicated.

On Fri, Mar 14, 2014 at 8:26 PM, docfaraday [email protected]:

I've experimented with some success with breaking the post-processing into
two phases, where the functions/macros/types/variables tables built from a
first scan of the csv files, and the _decldef tables built from a second
scan of the csv files, and omitting the update_decldef step. We'd need to
do something similar for the _refs tables, but first we'd need to teach the
clang plugin to output the qualname for 'ref' csv rows.

Reply to this email directly or view it on GitHubhttps://github.com//issues/257#issuecomment-37709944
.

from dxr.

I wonder if the scope information that DXR records could be useful here.

from dxr.