================
@@ -53,7 +56,23 @@ class ContributorFinder : public DynamicRecursiveASTVisitor {
DeclContext *DC = D->getDeclContext();
// Collects Decl for global variables or static data members:
- if (DC->isFileContext() || D->isStaticDataMember())
+ if (DC->isFileContext() || D->isStaticDataMember()) {
+ Contributors.insert(D);
+ return true;
+ }
+
+ // Optionally include block-scope (function-local) variables. Parameters
+ // are intentionally skipped: they are exposed via their parent function's
+ // USR + a parameter-index suffix in getEntityName, so registering them as
+ // independent contributors would be redundant.
+ //
+ // FIXME: clang::index::generateUSRForDecl can produce non-unique or empty
+ // USRs for some local declaration shapes (e.g., locals of certain template
+ // instantiations). The current addEntity path returns std::nullopt when
+ // that happens and downstream extractors skip gracefully, so this is
+ // tolerated for now.
+ if (Opts.IncludeLocalEntities && !D->isImplicit() && !isa<ParmVarDecl>(D)
&&
+ DC->isFunctionOrMethod())
----------------
jkorous-apple wrote:
"You are right to push back". This is more or less a NFC PR for the current
summaries.
The motivation is an upcoming SharedLexicalRepresentationAnalysis that we need
for source code rewriting. I have a WIP PR and will put it up next week. In a
nutshell, we need to summarize the source range for each declaration of each
entity so the analysis can consider entities with shared textual representation
as related. Transformation of one of them affects all of them.
What you said is true, we could technically follow the contribution model by
using some parent global entity as the key. Given that we will need this data
for every single entity, I was conscious of the data volume and simply didn't
want to spend extra time on implementing an inferior solution (more memory,
lower analysis performance). So, I decided to conditionally enable local
entities to be contributors and attached the list of declaration source ranges
to each entity directly.
https://github.com/llvm/llvm-project/pull/205351
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
