This matches behavior of other synthetic members like copy constructors,
and avoids RecursiveASTVisitor traversing TypeLocs that don't correspond
to any spelling of the type they describe.
Details
- Reviewers
ymandel aaron.ballman
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Sema/SemaDeclCXX.cpp | ||
---|---|---|
13895–13896 | I'm now suspicious of all TypeLocs in this code, and If I'm reading this code correctly, this typeloc is never actually used. | |
13908 | Once you're at it, should this use actually be nullptr? | |
13929 | nit: label with /* TypeSourceInfo=*/? | |
clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp | ||
2142–2144 | why phrase it bottom up, instead of top-down (matching the record decl and then using hasDescendant)? |
+Aaron for guidance & in case I'm making things up, TypeLocs/TSI have always confused me...
clang/lib/Sema/SemaDeclCXX.cpp | ||
---|---|---|
13895–13896 | My understanding is TypeLoc is really just a Type* + handle into some storage, TypeSourceInfo is typically that storage. The net effect: if we ask for the function's typeloc, and then ask that loc for the param decls, we'll get them, just the same as if we ask the function for its param decls directly. | |
13908 | ... maybe? For implicit copy-constructors, the TSI is nullptr (SemaDeclCXX.cpp:15425). I've done this as I agree TypeSourceInfo for implicit code is dubious, and I was able to construct a similar ASTMatcher misbehavior that this fixes. @aaron.ballman does this seem right? |
clang/lib/Sema/SemaDeclCXX.cpp | ||
---|---|---|
13908 | Errr... somewhere in the middle between right and wrong. I can see why TypeSourceInfo for implicit code is dubious, but we've had a theoretical long-standing goal that we've never seriously worked towards of replacing QualType/Type * with TypeSourceInfo * in many of our interfaces so that location information about types is more readily available. On balance, I think passing nullptr here is reasonable -- this is an implicit node and we do this for other implicitly created special member functions. | |
13929 | I think this change is potentially incorrect, at least judging by: https://github.com/llvm/llvm-project/blob/ce0d16f574f5bd81086e124345b0fe8dc4bfd95d/clang/lib/Sema/SemaDeclCXX.cpp#L15442 But then again: https://github.com/llvm/llvm-project/blob/ce0d16f574f5bd81086e124345b0fe8dc4bfd95d/clang/lib/Sema/SemaDeclCXX.cpp#L15584 So perhaps more investigation is needed here? |
I'm now suspicious of all TypeLocs in this code, and If I'm reading this code correctly, this typeloc is never actually used.