Commit Graph

12 Commits

Author SHA1 Message Date
Douglas Gregor a4b592a7d5 Switch more of Sema::CheckInitializerTypes over to
InitializationSequence. Specially, switch initialization of a C++
class type (either copy- or direct-initialization). 

Also, make sure that we create an elidable copy-construction when
performing copy initialization of a C++ class variable. Fixes PR5826.

llvm-svn: 91750
2009-12-19 03:01:41 +00:00
Douglas Gregor e1314a64b8 Switch the initialization required by return statements over to the
new InitializationSequence. This fixes some bugs (e.g., PR5808),
changed some diagnostics, and caused more churn than expected. What's
new:

  - InitializationSequence now has a "C conversion sequence" category
    and step kind, which falls back to
  - Changed the diagnostics for returns to always have the result type
    of the function first and the type of the expression second.
    CheckSingleAssignmentConstraints to peform checking in C. 
  - Improved ASTs for initialization of return values. The ASTs now
    capture all of the temporaries we need to create, but
    intentionally do not bind the tempoary that is actually returned,
    so that it won't get destroyed twice.
  - Make sure to perform an (elidable!) copy of the class object that
    is returned from a class.
  - Fix copy elision in CodeGen to properly see through the
    subexpressions that occur with elidable copies.
  - Give "new" its own entity kind; as with return values and thrown
    objects, we don't bind the expression so we don't call a
    destructor for it.

Note that, with this patch, I've broken returning move-only types in
C++0x. We'll fix it later, when we tackle NRVO.

llvm-svn: 91669
2009-12-18 05:02:21 +00:00
Douglas Gregor 723796af7a Eliminate Sema::CheckValueInitialization; its callers now use
InitializationSequence to perform the actual initialization.

Also, introduced the notion of a tree of initialized entities, so that
we can know where an initialization began when dealing with nested
initializations (as occur when performing list initialization). This
will, eventually, be useful for producing better diagnostics when list
initialization fails, because we can show the path from the top-level
object being initialized down to the actual subobject where
initialization failed.

llvm-svn: 91516
2009-12-16 06:35:08 +00:00
Douglas Gregor 85dabae6ad Switch the C++ new expression over to InitializationSequence, rather
than using its own partial implementation of initialization. 

Switched CheckInitializerTypes over to
InitializedEntity/InitializationKind, to help move us closer to
InitializationSequence.

Added InitializedEntity::getName() to retrieve the name of the entity,
for diagnostics that care about such things.

Implemented support for default initialization in
InitializationSequence.

Clean up the determination of the "source expressions" for an
initialization sequence in InitializationSequence::Perform.

Taught CXXConstructExpr to store more location information.

llvm-svn: 91492
2009-12-16 01:38:02 +00:00
Douglas Gregor 7dc42e5d4c Implement value initialization in InitializationSequence; untested
WIP, yet again.

llvm-svn: 91368
2009-12-15 00:01:57 +00:00
Douglas Gregor 4f84661c43 Minor cleanups for constructor initialization in InitializationSequence
llvm-svn: 91325
2009-12-14 20:57:13 +00:00
Douglas Gregor 1e7ffa7571 Constructor initialization for InitializationSequence. Untested WIP.
llvm-svn: 91323
2009-12-14 20:49:26 +00:00
Douglas Gregor 540c3b0e50 Implement user-defined conversions in InitializationSequence. WPI that
isn't turned on anyway yet, so it cannot be tested.

llvm-svn: 91294
2009-12-14 17:27:33 +00:00
Eli Friedman ad6c2e5b3a Fix a recent regression from the initialization changes.
llvm-svn: 91097
2009-12-11 02:42:07 +00:00
Douglas Gregor 51e77d5ab0 Move initialization via initializer list over to InitializationSequences.
llvm-svn: 91050
2009-12-10 17:56:55 +00:00
Douglas Gregor 3e1e527826 Reimplement reference initialization (C++ [dcl.init.ref]) using the
new notion of an "initialization sequence", which encapsulates the
computation of the initialization sequence along with diagnostic
information and the capability to turn the computed sequence into an
expression. At present, I've only switched one CheckReferenceInit
callers over to this new mechanism; more will follow.

Aside from (hopefully) being much more true to the standard, the
diagnostics provided by this reference-initialization code are a bit
better than before. Some examples:

p5-var.cpp:54:12: error: non-const lvalue reference to type 'struct
Derived'
      cannot bind to a value of unrelated type 'struct Base'
  Derived &dr2 = b; // expected-error{{non-const lvalue reference to
  ...
           ^     ~
p5-var.cpp:55:9: error: binding of reference to type 'struct Base' to
a value of
      type 'struct Base const' drops qualifiers
  Base &br3 = bc; // expected-error{{drops qualifiers}}
        ^     ~~

p5-var.cpp:57:15: error: ambiguous conversion from derived class
      'struct Diamond' to base class 'struct Base':
    struct Diamond -> struct Derived -> struct Base
    struct Diamond -> struct Derived2 -> struct Base
  Base &br5 = diamond; // expected-error{{ambiguous conversion from
      ...
              ^~~~~~~
p5-var.cpp:59:9: error: non-const lvalue reference to type 'long'
      cannot bind to
      a value of unrelated type 'int'
  long &lr = i; // expected-error{{non-const lvalue reference to type
      ...
        ^    ~

p5-var.cpp:74:9: error: non-const lvalue reference to type 'struct
Base' cannot
      bind to a temporary of type 'struct Base'
  Base &br1 = Base(); // expected-error{{non-const lvalue reference to
  ...
        ^     ~~~~~~

p5-var.cpp:102:9: error: non-const reference cannot bind to bit-field
'i'
  int & ir1 = (ib.i); // expected-error{{non-const reference cannot
  ...
        ^     ~~~~~~
p5-var.cpp:98:7: note: bit-field is declared here
  int i : 17; // expected-note{{bit-field is declared here}}
      ^

llvm-svn: 90992
2009-12-09 23:02:17 +00:00
Douglas Gregor c8c44b5d67 Improve source location information for C++ member initializers in a
constructor, by keeping the DeclaratorInfo* rather than just the type
and a single location.

llvm-svn: 90355
2009-12-02 22:36:29 +00:00