And also fix a bug where we may return a meaningless location.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/XRefs.cpp | ||
---|---|---|
430 | this is the 3rd time we are checking for Sym.Definition, what about moving the check on line 410 to down here? Then it would look something like this: LocatedSymbol Located; Located.PreferredDeclaration = DeclLoc; if (Sym.Definition) { auto MaybeDefLoc = indexToLSPLocation(Sym.Definition, MainFilePath); if (!MaybeDefLoc) { log("locateSymbolNamedTextuallyAt: {0}", MaybeDefLoc.takeError()); return; } Located.PreferredDeclaration = *MaybeDefLoc; Located.Definition = *MaybeDefLoc; } Located.Name = (Sym.Name + Sym.TemplateSpecializationArgs).str(); | |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
285 | i am not sure if this change is aligned with the whole idea. we are trying to make the matcher more explicit, so if user wants to assert on the definition being equal to some range I think they should be explicitly specifying it. so I believe this should keep passing llvm::None to underlying matcher. I know it is likely more work than this version, but otherwise we are not really making it explicit. |
clang-tools-extra/clangd/XRefs.cpp | ||
---|---|---|
430 | good point. | |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
285 | yeah, it seems odd. I think this function is used as a syntax sugar to check LocatedSymbol has the *same* decl/def range, most callers have this assumptions. options:
1 is my preference, what do you think? |
clang-tools-extra/clangd/unittests/XRefsTests.cpp | ||
---|---|---|
285 |
my reading of the previous state was: the real matcher treated llvm::None on the last parameter as a Dont care, it was basically ignoring the definition. hence the two parameter version was used in places where people didn't care about definition range (or even its existence). so this patch is changing the behaviour of this two parameter version from don't care to make sure they are equal, i am not saying that's a bad thing but it just feels like more implicit (which is against the idea of the patch).
renaming would be one way of dealing with implicitness here. i am just not sure if it is really worth it though. I don't really think the existing call sites had the idea of make sure def and decl range are identical in mind. so I would opt for 2nd option you proposed if that's ok with you. |
this is the 3rd time we are checking for Sym.Definition, what about moving the check on line 410 to down here? Then it would look something like this: