integral or enumeration type.

llvm-svn: 64256

llvm-svn: 64252

arrays and other structs/unions as an extension. Downgrade our error
to a warning. Fixes PR3540.

llvm-svn: 64239

llvm-svn: 64230

arguments. This commit covers checking and merging default template
arguments from previous declarations, but it does not cover the actual
use of default template arguments when naming class template
specializations.

llvm-svn: 64229

llvm-svn: 64223

gcc compat test suite results (Darwin x86-32 & -64):
--
# of expected passes		1110
# of unexpected failures	74
# of unresolved testcases	168
# of unsupported tests		2

llvm-svn: 64197

llvm-svn: 64195

disambiguation contexts, so that we properly parse template arguments
such as

  A<int()>

as type-ids rather than as expressions. Since this can be confusing
(especially when the template parameter is a non-type template
parameter), we try to give a friendly error message.

Almost, eliminate a redundant error message (that should have been a
note) and add some ultra-basic checks for non-type template
arguments.

llvm-svn: 64189

template parameters.

llvm-svn: 64188

ABI.

llvm-svn: 64187

template parameters when performing semantic analysis of a template-id
naming a class template specialization.

llvm-svn: 64185

llvm-svn: 64175

llvm-svn: 64173

llvm-svn: 64168

to tell it that it wasn't (directly) designated. This way, we unwind
back to the explicit initializer list properly rather than getting
stuck in the wrong subobject. Fixes llvm.org/PR3519

llvm-svn: 64155

to a class template. For example, the template-id 'vector<int>' now
has a nice, sugary type in the type system. What we can do now:

  - Parse template-ids like 'vector<int>' (where 'vector' names a
    class template) and form proper types for them in the type system.
  - Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly,
    using (sadly) a bool in the parser to tell it whether '>' should
    be treated as an operator or not.

This is a baby-step, with major problems and limitations:
  - There are currently two ways that we handle template arguments
  (whether they are types or expressions). These will be merged, and,
  most likely, TemplateArg will disappear.
  - We don't have any notion of the declaration of class template
  specializations or of template instantiations, so all template-ids
  are fancy names for 'int' :)

llvm-svn: 64153

References are not objects; implement this in Type::isObjectType().

llvm-svn: 64152

Fix PR 2514: Do not flag dead initializations for variables initialized to a constant global variable.

llvm-svn: 64149

than a Decl, which gives us some more flexibility to express the
results with the type system. There are no clients using this
flexibility yet, but it's meant to be able to describe qualified names
as written in the source (e.g., "foo::type") or template-ids that name
a class template specialization (e.g., "std::vector<INT>").

DeclSpec's TST_typedef has become TST_typename, to reflect its use to
describe types found by name (that may or may not be typedefs). The
type representation of a DeclSpec with TST_typename is an opaque
QualType pointer. All users of TST_typedef, both direct and indirect,
have been updated for these changes.

llvm-svn: 64141

llvm-svn: 64087

llvm-svn: 64085

llvm-svn: 64081

llvm-svn: 64080

llvm-svn: 64074

llvm-svn: 64047

llvm-svn: 64045

This uncovers some bugs, so several test cases now fail.

llvm-svn: 64025

llvm-svn: 64019

llvm-svn: 64015

llvm-svn: 63987

llvm-svn: 63985

llvm-svn: 63983

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

Add sub-testcase where we process Cocoa.h using --disable-free (i.e., test the usage of the BumpPtrAllocator in ASTContext).

llvm-svn: 63957

llvm-svn: 63952

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

llvm-svn: 63939

llvm-svn: 63930

for FieldRegion. This enables us to track more values.

Simplify SymbolicRegion::getRValueType(). We assume the symbol always has
pointer type.

llvm-svn: 63928

diffing the output of:
  clang -dM -o - -E -x c foo.c | sort

llvm-svn: 63926