for constructor initializations, e.g.,

  class A { };
  class B : public A { 
    int m;
  public:
    B() : A(), m(17) { };
  };

llvm-svn: 58749

llvm-svn: 58692

Diagnose use of 'this' in a C++ default argument. Thanks to Eli for correcting my bogus assertion about it already being handled

llvm-svn: 58691

llvm-svn: 58649

  X x(5, 7);

llvm-svn: 58641

cope with the case where a user-defined conversion is actually a copy
construction, and therefore can be compared against other standard
conversion sequences. While I called this a hack before, now I'm
convinced that it's the right way to go.

Compare overloads based on derived-to-base conversions that invoke
copy constructors. 

Suppress user-defined conversions when attempting to call a
user-defined conversion.

llvm-svn: 58629

when appropriate.

Conversions for class types now make use of copy constructors. I've
replaced the egregious hack allowing class-to-class conversions with a
slightly less egregious hack calling these conversions standard
conversions (for overloading reasons).

llvm-svn: 58622

reference-collapsing. 

Implement diagnostic for formation of a reference to cv void.

Drop cv-qualifiers added to a reference type when the reference type
comes from a typedef.

llvm-svn: 58612

llvm-svn: 58538

conversions.

Notes:
  - Overload resolution for converting constructors need to prohibit
    user-defined conversions (hence, the test isn't -verify safe yet).
  - We still use hacks for conversions from a class type to itself. 
    This will be the case until we start implicitly declaring the appropriate
    special member functions. (That's next on my list)

llvm-svn: 58513

llvm-svn: 58509

Notes:
  - Constructors are never found by name lookup, so they'll never get
    pushed into any scope. Instead, they are stored as an 
    OverloadedFunctionDecl in CXXRecordDecl for easy overloading.
  - There's a new action isCurrentClassName that determines whether an
    identifier is the name of the innermost class currently being defined;
    we use this to identify the declarator-id grammar rule that refers to 
    a type-name. 
  - MinimalAction does *not* support parsing constructors.
  - We now handle virtual and explicit function specifiers.

llvm-svn: 58499

llvm-svn: 58395

  - Allows definitions of overloaded functions :)
  - Eliminates extraneous error messages when we have a definition of a 
    function that isn't an overload but doesn't have exactly the same type
    as the original.
  

llvm-svn: 58382

llvm-svn: 58381

Temporary disable the const-object-declaration-without-initializer check, because it depends on linkage-specifier semantics we don't yet have

llvm-svn: 58377

ImplicitConversionSequence and, when doing so, following the specific
rules of [over.best.ics]. 

The computation of the implicit conversion sequences implements C++
[over.ics.ref], but we do not (yet) have ranking for implicit
conversion sequences that use reference binding.

llvm-svn: 58357

of copy initialization. Other pieces of the puzzle:

  - Try/Perform-ImplicitConversion now handles implicit conversions
    that don't involve references.
  - Try/Perform-CopyInitialization uses
    CheckSingleAssignmentConstraints for C. PerformCopyInitialization
    is now used for all argument passing and returning values from a
    function.
  - Diagnose errors with declaring references and const values without
    an initializer. (Uses a new Action callback, ActOnUninitializedDecl).
  
We do not yet have implicit conversion sequences for reference
binding, which means that we don't have any overloading support for
reference parameters yet.

llvm-svn: 58353

  - CastExpr is the root of all casts
  - ImplicitCastExpr is (still) used for all explicit casts
  - ExplicitCastExpr is now the root of all *explicit* casts
  - ExplicitCCastExpr (new name needed!?) is a C-style cast in C or C++
  - CXXFunctionalCastExpr inherits from ExplicitCastExpr
  - CXXNamedCastExpr inherits from ExplicitCastExpr and is the root of all
    of the C++ named cast expression types (static_cast, dynamic_cast, etc.)
  - Added classes CXXStaticCastExpr, CXXDynamicCastExpr, 
    CXXReinterpretCastExpr, and CXXConstCastExpr to 

Also, fixed returned-stack-addr.cpp, which broke once when we fixed
reinterpret_cast to diagnose double->int* conversions and again when
we eliminated implicit conversions to reference types. The fix is in
both testcase and SemaChecking.cpp.

Most of this patch is simply support for the renaming. There's very
little actual change in semantics.

llvm-svn: 58264

llvm-svn: 58252

When destroying a translation unit, deallocate its owned declarations in reverse order, because there may be dependencies among the declarations.

llvm-svn: 58244

Unbreak the test by.. removing a space. (clang protested that -verify only works on single input files).

llvm-svn: 58123

-Add withConst/withVolatile/withRestrict methods to QualType class, that return the QualType plus the respective qualifier.

llvm-svn: 58120

llvm-svn: 58100

llvm-svn: 58094

conversions.

Added PerformImplicitConversion, which follows an implicit conversion sequence
computed by TryCopyInitialization and actually performs the implicit
conversions, including the extra check for ambiguity mentioned above.

llvm-svn: 58071

pointer-to-base. Also, add overload ranking for pointer conversions
(for both pointer-to-void and derived-to-base pointer conversions).

Note that we do not yet diagnose derived-to-base pointer conversion
errors that stem from ambiguous or inacessible base classes. These
aren't handled during overload resolution; rather, when the conversion
is actually used we go ahead and diagnose the error.

llvm-svn: 58017

don't have duplicated direct base classes.

Seriliazation of base class specifiers is not yet implemented.

llvm-svn: 57991

conversions (e.g., comparing int* -> const int* against 
int* -> const volatile int*); see C++ 13.3.3.2p3 bullet 3.

Add Sema::UnwrapSimilarPointerTypes to simplify the control flow of
IsQualificationConversion and CompareQualificationConversion (and fix
the handling of the int* -> volatile int* conversion in the former).
 

llvm-svn: 57978

Fix a thinko in the qualification-conversion check when the qualificaitons are disjoint, and add some overloading-based tests of qualification conversions

llvm-svn: 57942

Changes:
  - Sema::IsQualificationConversion determines whether we have a qualification
    conversion.
  - Sema::CheckSingleAssignment constraints now follows the C++ rules in C++,
    performing an implicit conversion from the right-hand side to the type of
    the left-hand side rather than checking based on the C notion of 
    "compatibility". We now rely on the implicit-conversion code to
    determine whether the conversion can happen or
    not. Sema::TryCopyInitialization has an ugly reference-related
    hack to cope with the initialization of references, for now.
  - When building DeclRefExprs, strip away the reference type, since
    there are no expressions whose type is a reference. We'll need to
    do this throughout Sema.
  - Expr::isLvalue now permits functions to be lvalues in C++ (but not
  in C).

llvm-svn: 57935

llvm-svn: 57909

Tweak an expected-error to match the output. IMHO it is better to diagnose 'int (void)' because it has the same meaning in C and C++.

llvm-svn: 57901

Issue a warning when there's an ambiguous function declarator (that could be a direct initializer for a variable defition).
Idea originated from here: http://thread.gmane.org/gmane.comp.gcc.devel/101524

llvm-svn: 57609

typedef int f();
struct S {
   f *x; // incorrectly assuming this is function decl, leading to failed assertions.
};

llvm-svn: 57598

class C {
  static const int number = 50;
  static int arr[number];
};

Here's how it worked:
-GetTypeForDeclarator was called from both Sema::ActOnCXXMemberDeclarator and Sema::ActOnDeclarator.
-VariableArrayTypes are not uniqued so two VariableArrayTypes were created with the same DeclRefExpr.
-On exit they both tried to destroy that one DeclRefExpr.

The fix is not to use GetTypeForDeclarator from the Sema::ActOnCXXMemberDeclarator.

llvm-svn: 57313

In ParseParenDeclarator match "D.setGroupingParens(true);" with another setGroupingParens call after the ')' is parsed.
Fixes this bug:
  int (x)(0); // error, expected function declarator where the '(0)' initializer is

llvm-svn: 57241

This is how this kind of initializers appear in the AST:
-The Init expression of the VarDecl is a functional type construction (of the VarDecl's type).
-The new VarDecl::hasCXXDirectInitializer() returns true.

e.g, for "int x(1);":
-VarDecl 'x' has Init with expression "int(1)" (CXXFunctionalCastExpr).
-hasCXXDirectInitializer() of VarDecl 'x' returns true.

A major benefit is that clients that don't particularly care about which exactly form was the initializer can handle both cases without special case code.
Note that codegening works now for "int x(1);" without any changes to CodeGen.

llvm-svn: 57178

No funcitonality change.

llvm-svn: 57136

sizeof(int()) -> "int()" is type-id
sizeof(int()+1) -> "int()+1" is expression.

llvm-svn: 57131