Commit Graph

3 Commits

Author SHA1 Message Date
Douglas Gregor 589973b097 In C++98/03, an uninitialized variable that has POD class type will be
uninitialized. This seems not to be the case in C++0x, where we still
call the (trivial) default constructor for a POD class
(!). Previously, we had implemented only the C++0x rules; now we
implement both. Fixes PR6536.

llvm-svn: 97928
2010-03-08 02:45:10 +00:00
Douglas Gregor e6565625f4 Migrate the mish-mash of declaration checks in
Sema::ActOnUninitializedDecl over to InitializationSequence (with
default initialization), eliminating redundancy. More importantly, we
now check that a const definition in C++ has an initilizer, which was
an #if 0'd code for many, many months. A few other tweaks were needed
to get everything working again:

  - Fix all of the places in the testsuite where we defined const
    objects without initializers (now that we diagnose this issue)
  - Teach instantiation of static data members to find the previous
    declaration, so that we build proper redeclaration
    chains. Previously, we had the redeclaration chain but built it
    too late to be useful, because...
  - Teach instantiation of static data member definitions not to try
    to check an initializer if a previous declaration already had an
    initializer. This makes sure that we don't complain about static
    const data members with in-class initializers and out-of-line
    definitions.
  - Move all of the incomplete-type checking logic out of
    Sema::FinalizeDeclaratorGroup; it makes more sense in
    ActOnUnitializedDecl.

There may still be a few places where we can improve these
diagnostics. I'll address that as a separate commit.

llvm-svn: 95657
2010-02-09 07:26:29 +00:00
Douglas Gregor 7ae2d7758f Rework base and member initialization in constructors, with several
(necessarily simultaneous) changes:

  - CXXBaseOrMemberInitializer now contains only a single initializer
    rather than a set of initialiation arguments + a constructor. The
    single initializer covers all aspects of initialization, including
    constructor calls as necessary but also cleanup of temporaries
    created by the initializer (which we never handled
    before!).

  - Rework + simplify code generation for CXXBaseOrMemberInitializers,
    since we can now just emit the initializer as an initializer.

  - Switched base and member initialization over to the new
    initialization code (InitializationSequence), so that it

  - Improved diagnostics for the new initialization code when
    initializing bases and members, to match the diagnostics produced
    by the previous (special-purpose) code.

  - Simplify the representation of type-checked constructor initializers in
    templates; instead of keeping the fully-type-checked AST, which is
    rather hard to undo at template instantiation time, throw away the
    type-checked AST and store the raw expressions in the AST. This
    simplifies instantiation, but loses a little but of information in
    the AST.

  - When type-checking implicit base or member initializers within a
    dependent context, don't add the generated initializers into the
    AST, because they'll look like they were explicit.

  - Record in CXXConstructExpr when the constructor call is to
  initialize a base class, so that CodeGen does not have to infer it
  from context. This ensures that we call the right kind of
  constructor.

There are also a few "opportunity" fixes here that were needed to not
regress, for example:

  - Diagnose default-initialization of a const-qualified class that
    does not have a user-declared default constructor. We had this
    diagnostic specifically for bases and members, but missed it for
    variables. That's fixed now.

  - When defining the implicit constructors, destructor, and
    copy-assignment operator, set the CurContext to that constructor
    when we're defining the body.

llvm-svn: 94952
2010-01-31 09:12:51 +00:00