When diagnosing bad conversions, skip the conversion for ignored object
arguments.  Fixes PR 6398.

llvm-svn: 97090

pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr
node directly. Currently, this only affects pseudo-destructor
expressions when they are parsed, but not after template
instantiation. That's coming next...

Improve parsing of pseudo-destructor-names. When parsing the
nested-name-specifier and we hit the sequence of tokens X :: ~, query
the actual module to determine whether X is a type-name (in which case
the X :: is part of the pseudo-destructor-name but not the
nested-name-specifier) or not (in which case the X :: is part of the
nested-name-specifier). 

llvm-svn: 97058

Fixes PR6373.

llvm-svn: 97037

analysis needs this.

llvm-svn: 97014

Add support for the weakref attribute. We still produce "alias weak" as llvm-gcc does, but are more strict on what uses of weakref we accept.

llvm-svn: 96992

C++98/03 and C++0x, since the '0x semantics break valid C++98/03
code. This new mess is tracked by core issue 399, which is still
unresolved.

Fixes PR6358 and PR6359.

llvm-svn: 96836

errors, e.g.:

t.c:1:21: error: redefinition of parameter 'x'
int test(int x, int x);
                    ^
t.c:1:14: note: previous declaration is here
int test(int x, int x);
             ^

llvm-svn: 96769

  typedef int Int;
  int *p;
  p->Int::~Int();

This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.

llvm-svn: 96743

figure out how not to break lots of code using this. See PR6358 and PR6359 for
motivating examples. FIXME's left in the code and the test.

llvm-svn: 96733

test suite.

llvm-svn: 96608

types. Fixes <rdar://problem/7643909>.

llvm-svn: 96531

which describes temporary objects of class type in C++. Use this to
provide a more-specific, remappable diagnostic when takin the address
of such a temporary.

llvm-svn: 96396

disaster. Fixes PR6161.

llvm-svn: 96371

now cope with the destruction of types named as dependent templates,
e.g.,

  y->template Y<T>::~Y()

Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse

  template<typename T, typename U>
  X0<T, U>::~X0() { }

properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.

Fixes PR6152.

llvm-svn: 96367

llvm-svn: 96335

they are re-checked on instantiation.

llvm-svn: 96217

headers, where malloc (and many other libc functions) are declared
with empty throw specifications, e.g.,  

  extern void *malloc (__SIZE_TYPE__ __size) throw () __attribute__
  ((__malloc__)) ;

The C++ standard doesn't seem to allow this, and redeclaring malloc as
the standard permits (as follows) resulted in Clang (rightfully!)
complaining about mis-matched exception specifications.

  void *malloc(size_t size);

We work around this by silently propagating an empty throw
specification "throw()" from a function with C linkage declared in a
system header to a redeclaration that has no throw specifier.

Ick.

llvm-svn: 95969

llvm-svn: 95967

  ::__builtin_va_copy

Fixes one of the Firefox issues in PR5511.

llvm-svn: 95966

variable type, we can (and should) still check for completeness of the
variable's type. Do so, to work around an assertion that shows up in
Boost's shared_ptr.

llvm-svn: 95934

conversions.  Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path.  Prepare for friends.

llvm-svn: 95775

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

llvm-svn: 95640

types; we don't want to give an expression reference type. Fixes PR6177.

llvm-svn: 95635

llvm-svn: 95554

llvm-svn: 95553

llvm-svn: 95517

llvm-svn: 95487

llvm-svn: 95472

out-of-line initializers as integer constant expressions.  Fixes PR6206.

llvm-svn: 95463

is a constructor for that class, right? Fixes PR6238. 

llvm-svn: 95367

prevent a crash on templates when looking for an existing declaration of the
predefined global operators. This fixes PR5918.

Added an easy test case for the overload handling, but testing the crash is
a bit trickier. Created a new test that can use multiple runs with a define to
trigger which test case is used so we can test this type of issue.

llvm-svn: 95220

lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:

  const int i;
  (void)(i + 17);

the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it. 

We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
  - the left-hand side of a '.' operator
  - the left-hand side of an assignment
  - a C++ throw expression
  - a subscript expression that's subscripting a vector

Making this change exposed two issues with blocks:
  - we were deducing const-qualified return types of non-class type
  from a block return, which doesn't fit well
  - we weren't always setting the known return type of a block when it
  was provided with the ^return-type syntax

Fixes the current Clang-on-Clang compile failure and PR6076.

llvm-svn: 95167

llvm-svn: 94963

llvm-svn: 94958

llvm-svn: 94957

(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

sequences, where we would occasionally determine (incorrectly) that
one standard conversion sequence was a proper subset of another when,
in fact, they contained completely incomparable conversions. 

This change records the types in each step within a standard
conversion sequence, so that we can check the specific comparison
types to determine when one sequence is a proper subset of the
other. Fixes this testcase (thanks, Anders!), which was distilled from
PR6095 (also thanks to Anders).

llvm-svn: 94660

llvm-svn: 94565

This solution relies on an O(n) scan of redeclarations, which means it might
scale poorly in crazy cases with tons of redeclarations brought in by a ton
of distinct associated namespaces.  I believe that avoiding this
is not worth the common-case cost.

llvm-svn: 94530