dblaikie added a comment. (pulling this out of inline comments because Phab's reply quoting doesn't work so well there & the threading/ordering gets weird too)
>> Well, I'm hoping we can find a way to avoid doing that in the general case >> while still giving users a way to opt into that behavior if they need it for >> the C APIs or AST matching. > > Ah, I was figuring not wanting to diverge/provide toggles if we can help it - > like unused warnings, opt-in features may go undertested (especially for > these sort of operations being a bit subtle in some ways). Like we've > discussed (at least I remember it coming up many years ago) trying to unify > more of the static analyzer and IRGen to avoid divergence there - adding more > divergence between static analysis and IRGen/etc seems liable to create more > risk of bugs/inconsistencies. > > I definitely see the appeal to not having a toggle. I was envisioning was > more "generating an AST for matching over and C indexing API to create an AST > will set this flag" rather than "user-facing way to decide on the behavior in > arbitrary situations", but that does make testing more complicated because > the C index code wouldn't be generating the same AST as a "normal" > compilation. *nod* Perhaps it's not the end of the world - just my thoughts/concerns. I won't feel too poorly if you go another way with this. > Hmmm. This might be one of those times when we have to say "sorry, this is > what the AST looks like and these APIs operate on the AST" without making > changes. That would be pretty unfortunate because I think the use case from > @anderslanglands is reasonable, but it also doesn't seem reasonable enough to > warrant impacting the performance of all C++ compilations with Clang. 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". 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
