llvm-svn: 64085

llvm-svn: 64081

llvm-svn: 64047

llvm-svn: 64029

llvm-svn: 63998

- Made allocation of Stmt objects using vanilla new/delete a *compiler
  error* by making this new/delete "protected" within class Stmt.
- Now the only way to allocate Stmt objects is by using the new
  operator that takes ASTContext& as an argument.  This ensures that
  all Stmt nodes are allocated from the same (pool) allocator.
- Naturally, these two changes required that *all* creation sites for
  AST nodes use new (ASTContext&).  This is a large patch, but the
  majority of the changes are just this mechanical adjustment.
- The above changes also mean that AST nodes can no longer be
  deallocated using 'delete'.  Instead, one most do
  StmtObject->Destroy(ASTContext&) or do
  ASTContextObject.Deallocate(StmtObject) (the latter not running the
  'Destroy' method).

Along the way I also...
- Made CompoundStmt allocate its array of Stmt* using the allocator in
  ASTContext (previously it used std::vector).  There are a whole
  bunch of other Stmt classes that need to be similarly changed to
  ensure that all memory allocated for ASTs comes from the allocator
  in ASTContext.
- Added a new smart pointer ExprOwningPtr to Sema.h.  This replaces
  the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used
  'delete' to free memory instead of a Stmt's 'Destroy' method.

Big thanks to Doug Gregor for helping with the acrobatics of making
'new/delete' private and the new smart pointer ExprOwningPtr!

llvm-svn: 63997

llvm-svn: 63987

llvm-svn: 63983

llvm-svn: 63975

redeclarations. For example, checks that a class template
redeclaration has the same template parameters as previous
declarations.

Detangled class-template checking from ActOnTag, whose logic was
getting rather convoluted because it tried to handle C, C++, and C++
template semantics in one shot.

Made some inroads toward eliminating extraneous "declaration does not
declare anything" errors by adding an "error" type specifier.

llvm-svn: 63973

ASTContext. This required changing all clients to pass in the ASTContext& to the
constructor of StringLiteral. I also changed all allocations of StringLiteral to
use new(ASTContext&).

Along the way, I updated a bunch of new()'s in StmtSerialization.cpp to use the
allocator from ASTContext& (not complete).

llvm-svn: 63958

matching member exists. Thanks to Piotr Rak for reporting the problem!

llvm-svn: 63939

Also, put Objective-C protocols into their own identifier
namespace. Otherwise, we find protocols when we don't want to in C++
(but not in C).

llvm-svn: 63877

llvm-svn: 63866

extension. The interaction with designated initializers is a
bit... interesting... but we follow GNU's lead and don't permit too
much crazy code in this area.

Also, make the "excess initializers" error message a bit more
informative.

Addresses PR2561: http://llvm.org/bugs/show_bug.cgi?id=2561

llvm-svn: 63785

llvm-svn: 63784

llvm-svn: 63779

DeclTy*, not TypeTy*.

llvm-svn: 63756

llvm-svn: 63750

- Changes Lookup*Name functions to return NamedDecls, instead of
Decls. Unfortunately my recent statement that it will simplify lot of
code, was not quite right, but it simplifies some...
- Makes MergeLookupResult SmallPtrSet instead of vector, following
Douglas suggestions.
- Adds %qN format for printing qualified names to Diagnostic.
- Avoids searching for using-directives in Scopes, which are not
DeclScope, during unqualified name lookup.

llvm-svn: 63739

Fix <rdar://problem/6552648> error: redefinition of 'XCElementAnchorDelegate' as different kind of symbol.

At first glance, this looked like a recent regression (possibly created by http://llvm.org/viewvc/llvm-project?view=rev&revision=63354, which was the only recent change to this section of Sema::ActOnStartClassInterface()). After more investigation, it looks like an edge case bug that we didn't cover in our tests.

llvm-svn: 63738

llvm-svn: 63737

into the general name-lookup fold. This cleans up some ugly,
not-quite-working code in the handling of operator overloading.

llvm-svn: 63735

  unqualified-id '('

in C++. The unqualified-id might not refer to any declaration in our
current scope, but declarations by that name might be found via
argument-dependent lookup. We now do so properly.

As part of this change, CXXDependentNameExpr, which was previously
designed to express the unqualified-id in the above constructor within
templates, has become UnresolvedFunctionNameExpr, which does
effectively the same thing but will work for both templates and
non-templates.

Additionally, we cope with all unqualified-ids, since ADL also applies
in cases like

  operator+(x, y)

llvm-svn: 63733

a.k.a. Koenig lookup) in C++. Most of the pieces are in place, but for
two:

  - In an unqualified call g(x), even if the name does not refer to
    anything in the current scope, we can still find functions named
    "g" based on ADL. We don't yet have this ability.
  - ADL will need updating for friend functions and templates.

llvm-svn: 63692

llvm-svn: 63662

Pointers to functions don't work yet, and pointers to overloaded functions even less. Also, far too much illegal code is accepted.

llvm-svn: 63655

scopes where the name would be considered a redeclaration if we know
that we're declaring or defining that tag.

llvm-svn: 63647

using directives, from Piotr Rak!

llvm-svn: 63646

elaborated-type-specifier declarations into outer scopes while
retaining their proper lexical scope. This way is simpler and more
consistent with the way DeclContexts work, and also fixes

  http://llvm.org/bugs/show_bug.cgi?id=3430

llvm-svn: 63581

with Stmt/Expr nodes), and convert some of the more mundane
switch-on-all-decl-kinds uses over to use this new file.

llvm-svn: 63570

emit diagnostic when casting a ptr to a small int when doing static initialization (addresses Eli's comments I believe)

llvm-svn: 63562

llvm-svn: 63557

direct-initialization following a user-defined conversion can select
any constructor; it just can't employ any user-defined
conversions. So we ban those conversions and classify the constructor
call based on the relationship between the "from" and "to" types in
the conversion.

llvm-svn: 63554

non-ambiguous name lookup results without allocating any memory, e.g.,
for sets of overloaded functions.

llvm-svn: 63549

provides too few elements.

llvm-svn: 63525

llvm-svn: 63519

llvm-svn: 63517

llvm-svn: 63462

sequence. Previously, we weren't permitting the second step to call
copy constructors, which left user-defined conversion sequences
surprisingly broken.

Now, we perform overload resolution among all of the constructors, but
only accept the result if it makes the conversion a standard
conversion. Note that this behavior is different from both GCC and EDG
(which don't agree with each other, either); I've submitted a core
issue on the matter.

llvm-svn: 63450