royjacobson 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 ---------------- anderslanglands wrote: > 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? Why is the `__is_default_constructible` builtin type trait not enough? Do you have different behavior for user provided and implicit default constructors? 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
