[PATCH] D133979: [clangd] XRef functions treat visible class definitions as primary.
Kadir Cetinkaya via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Sep 16 02:57:28 PDT 2022
kadircet added inline comments.
================
Comment at: clang-tools-extra/clangd/XRefs.cpp:291
+ // (This exception matches the spirit of our indexing heuristics).
+ if (/*PreferDef=*/[&] {
+ if (Def == TD)
----------------
can we extract all of this into a `const TagDecl* getPublicDecl(const TagDecl* TD)` ?
================
Comment at: clang-tools-extra/clangd/XRefs.cpp:303
+ // decl is some other header.
+ return isHeaderFile(SM.getFileEntryRefForID(DefFile)->getName(),
+ D->getASTContext().getLangOpts());
----------------
nit: we actually have the main file name in ParsedAST, but it's probably not worth propagating that into here.
================
Comment at: clang-tools-extra/clangd/XRefs.cpp:303
+ // decl is some other header.
+ return isHeaderFile(SM.getFileEntryRefForID(DefFile)->getName(),
+ D->getASTContext().getLangOpts());
----------------
kadircet wrote:
> nit: we actually have the main file name in ParsedAST, but it's probably not worth propagating that into here.
reaching here actually implies user is in the same file that has the type definition (I know we were mostly discussing this for index behaviour, and our reasoning for the index makes completely sense) but I am not sure if taking the user to public declaration, when they're actually writing some code in the same file as the type's private implementation is still the right thing to do.
I think; if the definition is visible through AST, we should always prefer that, unless it's in a private header (which in theory we can detect here, as we've information about include graph).
do you think jumping to public interface is still desirable even when the user is already implementing something inside the private implementation file?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D133979/new/
https://reviews.llvm.org/D133979
More information about the cfe-commits
mailing list