llvm-svn: 106217

llvm-svn: 106216

llvm-svn: 106215

Make sure the caching mechanism in Parser::ParseLexedMethodDefs is robust against the parser reading too few tokens.

llvm-svn: 106214

In a line like:

(;

the semicolon leaves Parser:ParenCount unbalanced (it's 1 even though we stopped looking for a right paren).
This may affect later parsing and result in bad recovery for parsing errors.

llvm-svn: 106213

llvm-svn: 106212

llvm-svn: 106211

Also refactor the diagnostics so that we print out the kind of stack memory returned.

llvm-svn: 106210

type at the same location.

llvm-svn: 106209

1. builtins definitions for BuiltinsARM.def
2. intrinsic validation code for SemaChecking

Unsure as to whether this is the best way to handle the make dependencies or not.

llvm-svn: 106208

llvm-svn: 106206

Also removed the unused Aliases member.

llvm-svn: 106202

llvm-svn: 106196

didn't indicate violated invariants but that we weren't recovering well.

llvm-svn: 106195

llvm-svn: 106193

llvm-svn: 106189

llvm-svn: 106188

by inspecting the Store bindings instead of iterating over all the global variables
in a translation unit.  By looking at the store directly, we avoid cases where we cannot
directly load from the global variable, such as an array (which can result in an assertion failure)
and it also catches cases where we store stack addresses to non-scalar globals.
Also, but not iterating over all the globals in the translation unit, we maintain cache
locality, and the complexity of the checker becomes restricted to the complexity of the
analyzed function, and doesn't scale with the size of the translation unit.

This fixes PR 7383.

llvm-svn: 106184

the binding key instead of the region + offset.  It isn't clear if this is the best semantics, but most
clients will likely only care about simple bindings, or bindings to a particular variable.  We can
refine later if necessary.

llvm-svn: 106183

Correctly return early from BasicStoreManager::iterBindings() when the BindingsHandler returns false.

llvm-svn: 106182

"previous token" location at the end of the class definition. This
eliminates a badly-placed error + Fix-It when the ';' following a
class definition is missing. Fixes <rdar://problem/8066414>.

llvm-svn: 106175

Currently, there are two effective changes:

 - Attr::Kind has been changed to attr::Kind, in a separate namespace
   rather than the Attr class. This is because the enumerator needs to
   be visible to parse.
 - The class definitions for the C++0x attributes other than aligned are
   generated by TableGen.

The specific classes generated by TableGen are controlled by an array in
TableGen (see the accompanying commit to the LLVM repository). I will be
expanding the amount of code generated as I develop the new attributes system
while initially keeping it confined to these attributes.

llvm-svn: 106172

precise. Fixes PR7336.

llvm-svn: 106170

(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.

llvm-svn: 106167

disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.

llvm-svn: 106161

llvm-svn: 106151

template name that refers to such a parameter. It's amazing that this
problem didn't surface earlier. Fixes PR7387.

llvm-svn: 106147

llvm-svn: 106144

Moved check before we build the ObjCMessageExpr node.
(PR7386 related).

llvm-svn: 106139

(the last argument of the triple).

llvm-svn: 106131

complete before attempting to bind it to a temporary.
Fixes PR7386.

llvm-svn: 106130

llvm-svn: 106120

llvm-svn: 106118

llvm-svn: 106114

llvm-svn: 106113

llvm-svn: 106112

llvm-svn: 106111

of an explicit instantiation to an ExtWarn, since nobody else seems to
diagnose this problem.

llvm-svn: 106109

llvm-svn: 106108

decl. and one ddefined in darwin header file.

llvm-svn: 106107