llvm-svn: 86132

llvm-svn: 86131

that Clang diagnoses but GCC does not.

llvm-svn: 86130

(without complaining if it fails) to get proper semantics: reference
binding with a derived-to-base conversion and the enumeration of
constructors for user-defined conversions. There are probably more
cases to fix, but my prior attempt at statically ensuring that
complete-type checking always happens failed. Perhaps I'll try again.

With this change, Clang can parse include/llvm/*.h!

llvm-svn: 86129

DiagnoseSignCompare into Sema::CheckSignCompare and call it from more places.

Add some enumerator tests.  These seem to expose some oddities in the
types we're converting C++ enumerators to;  in particular, they're converting
to unsigned before int, which seems to contradict 4.5 [conv.prom] p2.

Note to self: stop baiting Doug in my commit messages.

llvm-svn: 86128

llvm-svn: 86127

llvm-svn: 86126

llvm-svn: 86122

in covariant thunks that return references.

llvm-svn: 86121

pointers are returned.

llvm-svn: 86120

llvm-svn: 86119

llvm-svn: 86118

llvm-svn: 86117

llvm-svn: 86116

llvm-svn: 86115

llvm-svn: 86114

invariants (diagnostics with source informations must occur between
{Begin,End}SourceFile).

llvm-svn: 86113

llvm-svn: 86112

llvm-svn: 86111

AnalysisManager: Don't rely on PathDiagnosicClients flushing their diagnostics when they are destroyed.

llvm-svn: 86110

of coverage of this from the analyzer.

If this bothers you, I can add it back in a mode where non-source diagnostics go
to stderr and only source diagnostics use -html-diags, but I don't think anyone
uses this.

llvm-svn: 86109

migrate work in the destructors of PathDiagnosticClients from their
destructors to FlushReports().  The destructors now currently call
FlushReports(); this will be fixed in a subsequent patch.

llvm-svn: 86108

This is conceptually correct, but adds a huge hack to HighlightMacros which is
in fact doing all sorts of mutation to the Preprocessor. See FIXME.

Chris, please review.

llvm-svn: 86107

a little fuzzy, but conceptually it's just uniquing the identifier.

Chris, please review. I debated splitting into const/non-const versions where
the const one propogated constness to the resulting IdentifierInfo*.

llvm-svn: 86106

llvm-svn: 86105

llvm-svn: 86104

llvm-svn: 86103

llvm-svn: 86102

Break anti-dependencies using free registers in a round-robin manner to avoid introducing new anti-dependencies.

llvm-svn: 86098

llvm-svn: 86097

llvm-svn: 86092

This fixes PR5393.

llvm-svn: 86091

This assert was very conservative to begin with (the error condition is well
covered by tests elsewhere in the code) so we won't miss much by removing it.

llvm-svn: 86088

still be dependent or invoke an overloaded operator. Previously, we
only supported builtin operators.

BinaryOperator/CompoundAssignOperator didn't have this issue because
we always built a CXXOperatorCallExpr node, even when name lookup
didn't find any functions to save until instantiation time. Now, that
code builds a BinaryOperator or CompoundAssignOperator rather than a
CXXOperatorCallExpr, to save some space.

llvm-svn: 86087

llvm-svn: 86086

llvm-svn: 86085

an "assign expression", representing the expressions where the value
binding occurs and the assignment takes place respectively.  These are
largely syntactic clues for better error reporting.

llvm-svn: 86084

Conditional operands are next.

Fixes part of rdar://problem/7289584.

llvm-svn: 86083

and compile with -mtriple to specify *-apple-darwin targets.

llvm-svn: 86081

llvm-svn: 86080