Default constructor created for non-default constructible type about castxml

[bradking]

CastXML has fairly elaborate infrastructure (and test cases) specifically to try to detect which implicitly members are valid. One can see the code here and here, and test cases here. The approach is to mark the implicit members as referenced (as if they were called) and suppress errors that Clang reports from doing so. The resulting structure we get from Clang normally marks failed declarations as invalid so we skip generating them. For some reason Clang is not doing that in this case.

Actually there is a test case close to the reported example here. However, it has an explicit default constructor because otherwise Clang warns:

.../test/input/Class-implicit-member-const.cxx:1:7: warning: class 'start' does not declare any constructor to initialize its non-modifiable members
class start {
      ^
.../test/input/Class-implicit-member-const.cxx:2:13: note: const member 'data' will never be initialized
  int const data;
            ^

The assumption made when the above-linked code was developed and test cases added was that this case is not useful in practice because it is not possible to use a class of this form. With a const data member one must define at least one constructor explicitly in order to initialize the member. Once such an explicit constructor is added then there is no implicit default constructor anyway.

What is the use case in practice for the example shown?

[praetorian20]

Brad, the class start example you pointed to is different from mine because my example has an aggregate. start in your example is not an aggregate because it has a private data member, so clang is right to complain about the absence of a user defined constructor in that case.

An aggregate with a const data member is still useful because I can either value initialize or aggregate initialize an instance - example.

The problem with the current behavior is that it's causing some tests in pygccxml to detect types such as the one in my example as trivially default constructible when they're actually not because of the presence of the const member.

[bradking]

Thanks, I hadn't noticed you're using an aggregate type. It looks like Clang correctly deletes the default constructor for C++11 and above. With -std=c++11 and -std=c++14 CastXML produces the correct output. It is only for -std=c++98 that the default constructor is incorrectly produced.

One can see that Clang treats the case differently depending on the language level:

$ cat test.cxx                                                                                                                               
struct foo {
  int const bar;
};
void f() {
  foo f;
}
$ clang++ test.cxx -std=c++98
test.cxx:1:8: error: implicit default constructor for 'foo' must explicitly initialize the const member 'bar'
struct foo {
       ^
test.cxx:2:13: note: declared here
  int const bar;
            ^
test.cxx:5:7: note: implicit default constructor for 'foo' first required here
  foo f;
      ^
1 error generated.
$ clang++ test.cxx -std=c++11
test.cxx:5:7: error: call to implicitly-deleted default constructor of 'foo'
  foo f;
      ^
test.cxx:2:13: note: default constructor of 'foo' is implicitly deleted because field 'bar' of const-qualified type 'const int' would not be initialized
  int const bar;
            ^
1 error generated.

[bradking]

I've added a test case in commit 816a57a to cover this. For C++98 the test is marked as "broken" to record this known limitation.

[bradking]

I found that clang::Sema::MarkFunctionReferenced skips semantic checking of trivial default constructors. We simply need to follow up with logic to force such checking. Fixed by commit 04b836b.

[praetorian20]

Awesome, thank you for looking into it further and finding a fix for C++03 also.