Return UnknownVal in RegionStoreManager::getSizeInElements() for unsupported regions.  This silences a warning when compiling Release-Asserts builds.

llvm-svn: 61818

to track down, easy to fix. This is on going.

llvm-svn: 61817

Fix <rdar://problem/5956221> clang ObjC rewriter: Microsoft-specific __fastcall keyword unrecognized.

This fix is C++ specific.

llvm-svn: 61816

llvm-svn: 61815

- Simplify ParseDeclCXX to use early exit on error instead of nesting.
- Change ParseDeclCXX to using the 'skip on error' form of ExpectAndConsume.
- If we don't see the ; in a using directive, still call the action, for 
  hopefully better error recovery.

llvm-svn: 61801

llvm-svn: 61800

llvm-svn: 61799

llvm-svn: 61798

llvm-svn: 61797

MaybeParseTypeSpecifier -> ParseOptionalTypeSpecifier.

llvm-svn: 61796

llvm-svn: 61795

llvm-svn: 61794

driver to lookup this way instead of manually scanning arguments in
multiple places.

llvm-svn: 61793

llvm-svn: 61792

llvm-svn: 61791

llvm-svn: 61790

information for declarations that were referenced via a qualified-id,
e.g., N::C::value. We keep track of the location of the start of the
nested-name-specifier. Note that the difference between
QualifiedDeclRefExpr and DeclRefExpr does have an effect on the
semantics of function calls in two ways:
  1) The use of a qualified-id instead of an unqualified-id suppresses
     argument-dependent lookup
  2) If the name refers to a virtual function, the qualified-id
  version will call the function determined statically while the
  unqualified-id version will call the function determined dynamically
  (by looking up the appropriate function in the vtable).

Neither of these features is implemented yet, but we do print out
qualified names for QualifiedDeclRefExprs as part of the AST printing.

llvm-svn: 61789

shorter and  more accurate.  The type name might not be qualified.

llvm-svn: 61788

llvm-svn: 61787

llvm-svn: 61786

InputArg and UnknownArg.
 - Every argument now always corresponds to some option, which
   simplifies other code.

llvm-svn: 61783

- 'Buffer' is now private and must be accessed via 'getBuffer()'.
   This paves the way for lazily mapping in source files on demand.
- Added 'getSize()' (which gets the size of the content without
   necessarily accessing the MemBuffer) and 'getSizeBytesMapped()'.
- Modifed SourceManager to use these new methods.  This reduces the
  number of places that actually access the MemBuffer object for a file
  to those that actually look at the character data.

These changes result in no performance change for -fsyntax-only on Cocoa.h.

llvm-svn: 61782

llvm-svn: 61780

llvm-svn: 61770

avoid the version of Preprocessor::getSpelling that returns an 
std::string.

llvm-svn: 61769

Improve ext vector test case.

llvm-svn: 61766

llvm-svn: 61764

llvm-svn: 61763

 - I'm not sure this is appropriate, but it seems reasonable to be
   able to call getFloatingRank on anything which isFloatingType().

llvm-svn: 61758

llvm-svn: 61747

Make C++ classes track the POD property (C++ [class]p4)
Track the existence of a copy assignment operator.
Implicitly declare the copy assignment operator if none is provided.
Implement most of the parsing job for the G++ type traits extension.
Fully implement the low-hanging fruit of the type traits:
__is_pod: Whether a type is a POD.
__is_class: Whether a type is a (non-union) class.
__is_union: Whether a type is a union.
__is_enum: Whether a type is an enum.
__is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1).

llvm-svn: 61746

 - Entry point is tools/ccc/xcc until we are a functional replacement
   for ccc.

This is highly experimental (FIXME/LOC ratio of 3.4%), quite crufty,
and barely usable (and then only on my specific Darwin). However, many
of the right ideas are present, and it already fixes a number of
things gcc gets wrong.

The major missing component is argument translation for tools
(translating driver arguments into cc1/ld/as/etc. arguments). This is
a large part of the driver functionality and will probably double the
LOC, but my hope is that the current architecture is relatively
stable.

Documentation & motivation to follow soon...

llvm-svn: 61739

llvm-svn: 61737

DeclContexts whose members are visible from enclosing DeclContexts up
to (and including) the innermost enclosing non-transparent
DeclContexts. Transparent DeclContexts unify the mechanism to be used
for various language features, including C enumerations, anonymous
unions, C++0x inline namespaces, and C++ linkage
specifications. Please refer to the documentation in the Clang
internals manual for more information.

Only enumerations and linkage specifications currently use transparent
DeclContexts.

Still to do: use transparent DeclContexts to implement anonymous
unions and GCC's anonymous structs extension, and, later, the C++0x
features. We also need to tighten up the DeclContext/ScopedDecl link
to ensure that every ScopedDecl is in a single DeclContext, which
will ensure that we can then enforce ownership and reduce the memory
footprint of DeclContext.

llvm-svn: 61735

their length.

llvm-svn: 61734

llvm-svn: 61700

isn't worth the complexity and the code already does a ton of lookahead.

llvm-svn: 61671

llvm-svn: 61668

early exit for C and avoid template lookup for C.

llvm-svn: 61667

not in backtracking mode.  This was just using the wrong predicate.

llvm-svn: 61666