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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
