This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Do not report anonymous entities in findExplicitReferences
ClosedPublic

Authored by ilya-biryukov on Oct 28 2019, 6:31 AM.

Details

Summary

Otherwise every client dealing with name location should handle
anonymous names in a special manner.

This seems too error-prone, clients can probably handle anonymous
entities they care about differently.

Diff Detail

Event Timeline

ilya-biryukov created this revision.Oct 28 2019, 6:31 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 28 2019, 6:31 AM

Stumbled upon it when trying to move semantic highlight to use findExplicitReferences.
This will create some trouble for D68937, but I believe it's actually worth it. NameLoc was never intended to point outside the name token.

We should be better off without anonymous names here in the long run.

hokein accepted this revision.Oct 28 2019, 6:36 AM
hokein added inline comments.
clang-tools-extra/clangd/FindTarget.cpp
454

nit: I think if (!ND->getDeclName().getAsIdentifierInfo()) is enough, getAsIdentifierInfo returns null if the name is not an identifier.

This revision is now accepted and ready to land.Oct 28 2019, 6:36 AM
kadircet added inline comments.Oct 28 2019, 6:41 AM
clang-tools-extra/clangd/FindTarget.cpp
453

i believe this will break D68937, which relies on findExplicitReferences to even rename unnamed parameters.

Build result: pass - 59699 tests passed, 0 failed and 763 were skipped.
Log files: cmake-log.txt, ninja_check_all-log.txt, CMakeCache.txt

This revision was automatically updated to reflect the committed changes.
ilya-biryukov marked an inline comment as done.Oct 28 2019, 6:48 AM
ilya-biryukov added inline comments.
clang-tools-extra/clangd/FindTarget.cpp
453

That's true, we'll have to handle them separately.

It's a bit more code, but I think it's worth it: having a name location pointing to commas or closing parentheses is super unexpected, having some custom logic to name unnamed things is probably a bit more code, but it should be less surprising.
Sorry about that.

454

Good point, I've also tried that, but ended up with the current version.

The proposed solution also removes references to constructors (and I presume various special names like operator+, etc.)
I'm not sure what to do with those, they pose a different problem: unlike anonymous names, they're actually spelled out in the source code.

However, having a single SourceLocation is definitely not enough to figure out the interesting source ranges, so we'll have to send more information about the name location to the clients...

I'm currently considering saving a DeclarationNameInfo in the ReferenceLoc, but I'll need to check whether that's actually possible in all cases, so decided to move this into a separate change.