Find References finds the wrong references

[timur]

This has been one of my pet peeves in Slickedit for a very long time, and I really think you guys need to fix this bug.

Example:

I have this structure:

struct qe_bd {
        u16 status;
        u16 length;
        u32 buf;
};

If the cursor is on "status", and I press Ctrl-/, I get a list of references for every instance of "status", even those that do not belong to structure qe_bd.  The odd thing is that in the References windows, it says

       Symbol: status(qe_bd:var)

So it knows which structure to use, but it doesn't limit its search to just that structure.  I work with the Linux kernel, and as you can imagine, there are hundreds of different structures with a field called "status".

On top of that, the References window lists every file in my project, and then it says "NO REFERENCES" for those files that don't have any references.  How do I turn THAT off?

[srouleau]

You may also want to check this thread too: http://community.slickedit.com/index.php?topic=545.0

It's better than it was, but at times it still feels like it's doing a text search rather than C++ tree parse.

[timur]

I applied the hotfixes, but it didn't fix anything.  The only difference now is that it takes much longer, but it still shows all of the erroneous references, and it still shows hundreds of files with "NO REFERENCES".

[hs2]

Maybe it's getting even worse (due to the huge code base of the linux kernel), but if you turn OFF 'find ref.s incrementally' you shouldn't get all these false matches.
Inc. find ref.s lists all files which 'could' contain a ref.
Each file is parsed 'on demand' if you do a 'find-next/-prev'.

I agree, that there should be an option like 'restrict to struct/class member'.
This would help a lot...

HS2

[Dennis]

Would you be willing to give us an example of one of the false-positives?

The references engine basically uses an inverted file index that tells us which files a particular identifier occurs in.  We then chug through all those files and look for occurrences of that identifier.  For each occurrence, we see if it maps back to the symbol that you are trying to find references to.  There are three different scenarios.

1) The identifier maps to the symbol you are looking for references to.  Count it as a reference.

2) The identifier maps to something totally different.  Do not count it as a reference.

3) The identifier doesn't map to anything, or context tagging gets an error when it tries to look up the symbol.  In this case, we still count it as a reference, because we just don't know if it is a convoluted reference, or just junk code.  I admit, 99% of the time, it's junk code, but it's better to error on the side of plenty, so for that 1% where it is a valid reference, we put it in the list.

If you are getting false positives, then you are probably in "case 3" territory.  To verify that, go to that occurrence, and hit go to definition.  If tagging can't find the precise symbol to jump to, then the question is what is wrong with that occurrence?  Is it in #if 0'd code?  Is there preprocessing around it that makes the code unparsable?  Are all the libraries used by that code tagged?

Dont' be so quick to conclude that the references engine is a "text search", it is a lot more than that, but if tagging is not configured properly, well, as the saying goes, what comes out matches what goes in.