dblaikie added a comment. In D135557#3871622 <https://reviews.llvm.org/D135557#3871622>, @aaron.ballman wrote:
> In D135557#3871482 <https://reviews.llvm.org/D135557#3871482>, @dblaikie > wrote: > >> I was hoping the rephrasing (is this really a question about which ctors the >> type has, or about how the type can be constructible) might offer us a way >> out for this use case, at least - if it's about how the type is >> constructible, then the AST wouldn't be the ideal/complete solution anyway >> and we could move more towards exposing the 5 special member ops as "can I >> do this thing/would this expression be valid". > > FWIW, I'm about 99% sure there's no way to do that without use of `Sema`, > which would require significant work to expose to the C indexing APIs and to > AST matchers. Fair enough :/ not sure what to do about that. > At the AST level, we have "does this type have these methods" but it requires > semantic analysis to determine whether something is copy constructible or > not. e.g., > > struct S { > S(S&) {} > }; > > This class has a usable copy constructor, yet it is not copy constructible > per the type trait: https://godbolt.org/z/srefPjzxj Ah, indeed, the inverse case - technically a copy ctor, but not one you can use in the ways you'd expect. Perhaps another question for @anderslanglands to consider. (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) 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. 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
