Support C++20 constinit variables for AST Matchers.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm going to use this matcher very soon in my new clang-tidy check.
If you're interested and want to read more, I have a design document about my ne check - here (gist.github.com) is the concrete check for constinit variables.
I think an ASTMatcher would be good, because:
- As far I tried there is no way to get only constinit variables in clang-query (?)
- The way to check in code if a variable is constinit is not quite obvious. A user may expect Node.isConstinit() (because Node.isConstexpr() works), but it's not working. The user has to examine AST and grep until they find Node.hasAttr<ConstInitAttr>().
P. S. If this commit will be accepted, kindly please commit it on my behalf, because I can't do it =) You can use my name Evgeny Shulgin and izaronplatz@gmail.com
clang/include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
5223 | This isn't quite correct -- there are two forms of ConstInitAttr: constinit int i = 0; // We want to match this one [[clang::require_constant_initialization]] int j = 0; // We don't want to match this one We typically want AST matchers to model the AST and this one does not... but, I think it is okay. constinit was based on the implementation experience we got with [[clang::require_constant_initialization]] and so we continue to model it as an attribute rather than a bit on the AST node. Having this matcher helps to distinguish the cases (otherwise we could just use the hasAttr() matcher instead). I think the logic here should be: if (const auto *CIA = Node.getAttr<ConstInitAttr>()) return CIA->isConstinit(); return false; and you should add a test case + documentation to show that we don't match the attribute form. |
clang/include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
5223 | Thank you! Very valuable information. It opened my eyes why is constinit unexpectedly parsed like an attribute. Another plus of the new matcher - users won't search for constinit incorrectly as I did before the fix. I added an explicit example to docs showing that the clang attribute won't work. |
I've commit on your behalf in 589a93907222cf2380198ca2172ff6697dd43d87, thanks for the new matcher!
This isn't quite correct -- there are two forms of ConstInitAttr:
We typically want AST matchers to model the AST and this one does not... but, I think it is okay. constinit was based on the implementation experience we got with [[clang::require_constant_initialization]] and so we continue to model it as an attribute rather than a bit on the AST node. Having this matcher helps to distinguish the cases (otherwise we could just use the hasAttr() matcher instead).
I think the logic here should be:
and you should add a test case + documentation to show that we don't match the attribute form.