anderslanglands added inline comments.
================ Comment at: clang/bindings/python/clang/cindex.py:1530 + + def record_needs_implicit_default_constructor(self): + """Returns True if the cursor refers to a C++ record declaration ---------------- royjacobson wrote: > aaron.ballman wrote: > > aaron.ballman wrote: > > > I don't think we should expose any of the "needs" functions like this -- > > > those are internal implementation details of the class and I don't think > > > we want to calcify that into something we have to support forever. As we > > > add members to a class, we recalculate whether the added member causes us > > > to delete defaulted special members (among other things), and the "needs" > > > functions are basically used when the class is completed to handle lazily > > > created special members. I'm pretty sure that lazy creation is not > > > mandated by the standard, which is why I think the "needs" functions are > > > more of an implementation detail. > > CC @erichkeane and @royjacobson as folks who have been in this same area of > > the compiler to see if they agree or disagree with my assessment there. > I think so. The 'needs_*' functions query `DeclaredSpecialMembers` and I'm > pretty sure it's modified when we add the implicit definitions in the class > completion code. So this looks a bit suspicious. Is this API //meant// to be > used with incomplete classes? > For complete classes I think looking up the default/move/copy constructor and > calling `isImplicit()` is the way to do it. > > About the 'is deleted' API - can't the same be done for those functions as > well so we have a smaller API? > > If this //is// meant to be used with incomplete classes for efficiency that > would be another thing, I guess. > So the intended use case here is I'm using libclang to parse an existing C++ libray's headers and generate a C interface to it. To do that I need to know if I need to generate default constructors etc, which the needs* methods do for me (I believe). The alternative is I have to check manually whether all the constructors/assignment operators exist, then implement the implicit declaration rules myself correctly for each version of the standard, which I'd rather avoid. Would putting a note in the doc comment about the behaviour differing when the class is being constructed as originally suggested work for everyone? 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
