[PATCH] D135557: Add needsImplicitDefaultConstructor and friends

Thu Oct 20 14:07:29 PDT 2022

dblaikie added a comment.

In D135557#3871803 <https://reviews.llvm.org/D135557#3871803>, @aaron.ballman wrote:

> In D135557#3871716 <https://reviews.llvm.org/D135557#3871716>, @dblaikie wrote:
>
>> (I'm still sort of curious how the AST matchers deal with all this - I guess they must have Sema available, because I'd assume they make all sorts of queries like "is this constructible from that" - since they're often trying to generate new code and want to know what constructs will be valid, which is different from the indexing use case, admittedly)
>
> Nope, AST matchers don't have Sema available, so they don't have a way to query "is this constructible from that". You've got the AST itself (and the `ASTContext`) and not a whole lot else beyond that.

Huh, that quite surprises me as to how some transformations are implemented in that situation. I guess maybe the more syntactically interesting ones are actual clang warnings with fixits, exposed via clang-tidy, so they have sema and all.

>> Maybe the answer is the C API isn't for this sort of thing/it's too nuanced to expose there?
>>
>> But if you reckon the inconsistency isn't so bad, I won't be up in arms if you decide to go with having the indexing C API instantiate all the implicit special members all the time. I can see the value/it's only restricted to the indexing API. Does seem a bit unfortunate in tetrms of consistency.
>
> Yeah, I think you convinced me that the consistency issue is something we should be wary of. I don't think we want to get into a situation where C index/AST matching is fundamentally a different AST than the rest of the compiler.

:/ sorry I don't have other great ideas to workaround these tradeoffs.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135557/new/

https://reviews.llvm.org/D135557