967721 - Calls to operator[] produce non-optimal links due to overlapping refs

Status: RESOLVED FIXED

(Webtools Graveyard :: DXR, defect)

Description

[James Abbatiello]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140127194636

Steps to reproduce:

Consider the following example code:
struct Foo
{
    void operator[](int) {}
};

int main()
{
    Foo foo;
    int idx = 42;
    foo[idx];
    return 0;
}



Actual results:

In the line "foo[idx]", "foo" is linked to the foo variable and "[idx]" is linked to the operator[] method.  There is no link to "idx".


Expected results:

We used to provide links to all three with "foo" linked to foo, "[" linked to operator[] and "idx" linked to idx.  This seems preferable to the current behavior but I'd consider other options as long as all three are available.  Specifically we may want to consider having "]" also linked to operator[].

Comment 1

[Erik Rose [:erik][:erikrose]]

Some notes from our IRC conversation:

I'm not sure what I would have changed that would cause it to behave differently. Overlapping refs have always been an error. It's possible that we now resolve them differently. The current philosophy is "Hey, that's wrong. Go fix your plugin. I just ignored any overlapping refs except one." We could...

* Fix the plugin
* Make the region resolver try to come up with a way to represent it, resulting in the old behavior (though this wouldn't work for all possible overlaps)
* Combine any overlapping regions into one menu. Disambiguate somehow, like {"Definition of operator[]", "Declaration of idx", ...}

Comment 2

[James Abbatiello]

I think this was fixed (or at least worked around) by https://github.com/mozilla/dxr/commit/4281805bde0ded22789d2c4f125b8a6b88a322c1 .  Erik, do you want to resolve this?

Comment 3

[Erik Rose [:erik][:erikrose]]

Thanks, James!