[cfe-dev] better way to test for explicit C++ constructor?

[John McCall]

On Dec 11, 2012, at 4:08 PM, Peeter Joot <peeter.joot at gmail.com> wrote:
> I'm rather confused by this whole thread; for the given analysis, I
> don't see how any constructor other than the one actually used to
> construct the global in question matters.
> 
> 
> The problem I was trying to solve is illustrated by:
> 
> struct nowHasConstructor
> {
>    int x ;
> 
>    withConstructor() : x(3) {} // Constructor added to solve uninitialized variable problem with uses of this type on the stack.
> } ;
> 
> struct b
> {
>    nowHasConstructor d ;
> } ;
> 
> struct a
> {
>    b c ;
> } ;
> 
> struct bigDisgustingStructureContainingWayTooManyOfTheTypesInOurProduct
> {
>    // ... lots of stuff
> 
>    struct a ; 
> 
>    // ... lots more stuff
> } ;
> 
> bigDisgustingStructureContainingWayTooManyOfTheTypesInOurProduct     theBigGiantGlobalVariable ;
> 
> I'd added the constructor for good reasons and it should solve the usage problems we have with this type in some cases.  However, the type in question also ends up indirectly included in the big ugly global.
> 
> That big ugly global can't have global constructors due to an AIX issue: a pure-C linked app won't invoke global constructors from a C++ shared lib unless it is dynamically loaded.  For this reason we forbid global  constructors in our "application" library, at least on AIX.  On that platform, we explicitly fail our link of this library if we find a linker reference to such a constructor (deleting the library in the make rule).
> 
> This question was motivated by me trying to track down what made theBigGiantGlobalVariable now require construction (I knew what change triggered this but not exactly where it caused the trouble).  I found it three levels deep in a couple of places (not obvious by inspection, but my AST visitor  was able to help me find it, since I was able to dump all the direct and indirect dependencies of the bigDisguistingType).

But why not instead just directly look at the initializer for theBigGiantGlobalVariable, which will be a CXXConstructExpr pointing directly to the default constructor?  You can then walk over the initializers in that constructor — which, since it's an implicitly-defined default constructor, should all be non-trivial — and see what constructors they use, etc.

Anyway, this would also be a reasonable enhancement request for -Wglobal-constructors;  we could easily say:
  warning: declaration requires a global constructor
  ...
  note: because type 'a' has a non-trivial default constructor
  note: because type 'b' has a non-trivial default constructor
  note: because type 'nowHasConstructor' has a non-trivial default constructor

Although it would be even better if these notes were compressed to:
  note: because the subobject 'foo.bar.baz' has a non-trivial default constructor
(that is, walking through implicitly-defined default constructors)

John.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121211/a1b650c0/attachment.html>