[PATCH] D135557: Add needsImplicitDefaultConstructor and friends

Thu Oct 20 08:36:22 PDT 2022

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