llvm-svn: 140180

rdar://10125227

llvm-svn: 140179

erronously trigger the digraph correction fix-it.  Include a new test to catch
this in the future.

llvm-svn: 140175

llvm-svn: 140174

llvm-svn: 140171

of Mips32 big and little endian derive.

llvm-svn: 140170

UnwindException structure is 32 for mips64. 

llvm-svn: 140165

[analyzer] Refactor PathDiagnosticLocation: Use PointerUnion of LocationContext and AnalysisContext to support creation of PathDiagnosticLocations for checkers which no context sensitivity.

llvm-svn: 140162

llvm-svn: 140161

from unfriendly (== not at all modularized) directories. This is
temporary, and it only affects module construction until I'll figured
out how to deal with system headers.

llvm-svn: 140159

llvm-svn: 140155

llvm-svn: 140149

llvm-svn: 140147

llvm-svn: 140146

change __builtin_va_list to from a structure to int[4] (same alignment
and size, but with a simpler representation). Patch by David Meyer!

llvm-svn: 140144

Per John's review comments for r140068.

llvm-svn: 140142

presence of an implicit move assignment operator.  I think the implicit
copy assignment operator case was also wrong, but just in a "displaying
the wrong diagnostic" way.

llvm-svn: 140139

of false positive warnings that depend on noreturn destructors pruning
the CFGs, but only in C++0x mode!

This was really surprising as the debugger quickly reveals that the
attributes are parsed correctly (and using the same code) in both modes.
The warning fires in the same way in both modes. But between parsing and
building the destructor declaration with the noreturn attribute and the
warning, it magically disappears. The key? The 'noexcept' appears!

When we were rebuilding the destructor type with the computed implicit
noexcept we completely dropped the old type on the floor. This almost
makes sense (as the arguments and return type to a destructor aren't
exactly unpredictable), but lost any function type attributes as well.
The fix is simple, we build the new type off of the old one rather than
starting fresh.

Testing this is a bit awkward. I've done it by running the
noreturn-sensitive tests in both modes, which previous failed and now
passes, but if anyone has ideas about how to more specifically and
thoroughly test that the extended info on a destructor is preserved when
adding noexcept, I'm all ears.

llvm-svn: 140138

[analyzer] Refactor PathDiagnosticLocation: Pre-compute Range and Location with gen methods on object creation instead of computing on demand. This would allow to remove dependency on the other members which help with construction and might not even be valid at later stages (to be removed later on).

llvm-svn: 140131

llvm-svn: 140130

llvm-svn: 140123

llvm-svn: 140100

llvm-svn: 140092

llvm-svn: 140091

Add list initialization for complex numbers in C.  Essentially, this allows "_Complex float x = {1.0f, 2.0f};".  See changes to docs/LanguageExtensions.html for a longer description.

<rdar://problem/9397672>.

llvm-svn: 140090

check for the landingpad instruction instead. This check looks at each of the
clauses in the landingpad instruction. If it's a catch clause, it compares the
name directly with the global. If it's a filter clause, it has to look through
each value in the filer to see if any have the prefix.

llvm-svn: 140075

llvm-svn: 140073

llvm-svn: 140068

llvm-svn: 140066

PreprocessingRecord's getPreprocessedEntitiesInRange.

Also remove all the stuff that were added in ASTUnit that are unnecessary now
that we do a binary search for preprocessed entities and deserialize only
what is necessary.

llvm-svn: 140063

return iterators for local, non-loaded, preprocessed entities.

llvm-svn: 140062

instead of getLocation() since we don't care about expanded macro arguments.

llvm-svn: 140061

check whether the requested location points inside the precompiled preamble,
in which case the returned source location will be a "loaded" one.

llvm-svn: 140060

source location of line:col of a specific FileID.

llvm-svn: 140059

which will do a binary search and return a pair of iterators
for preprocessed entities in the given source range.

Source ranges of preprocessed entities are stored twice currently in
the PCH/Module file but this will be fixed in a subsequent commit.

llvm-svn: 140058

It already works (and is useful with) macro locs as well.

llvm-svn: 140057

depend on internal knowledge of SourceLocation.

llvm-svn: 140056

llvm-svn: 140055

llvm-svn: 140054

inside a macro argument should be regarded as coming before
the location of the expanded tokens.

llvm-svn: 140053