vector<int>

to

  std::vector<int>

Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.

Thanks Kaelyn!

llvm-svn: 134007

Fix PR9279 - Macro expansion stack trace seriously broken with function-style macros, by not recursively printing notes for other 'instantiated from' notes.

This is a one line fix here:
+      // Don't print recursive instantiation notes from an instantiation note.
+      Loc = SM.getSpellingLoc(Loc);

While here, fix the testcase to be more precise (it got filecheck'ized
brutally), and fix EmitCaretDiagnostic to be private and to not pass down
the unused 'Level' argument.

llvm-svn: 133993

from Sema::GetTypeForDeclarator. No functionality change.

llvm-svn: 133987

Sema::GetTypeForDeclarator and remove its 'OwnedDecl' out parameter.

No functionality change.

llvm-svn: 133986

Centralize the check for a tag definition in a Declarator::PrototypeContext inside GetTypeForDeclarator.
No functionality change.

llvm-svn: 133985

No functionality change.

llvm-svn: 133984

// rdar://7811841

llvm-svn: 133970

only to pointers to locals.  But it should work inside blocks, too.

llvm-svn: 133969

Merge some calls to FoldingSetNodeID::AddInteger; assuming my measurements aren't completely off, roughly a 1% speedup on SingleSource/UnitTests/ObjC/trivial-interface.m .

llvm-svn: 133968

for explicit specializations with their own explicit visibility.

llvm-svn: 133958

llvm-svn: 133943

functions with arguments of transparent unions type.
// rdar://9584012

llvm-svn: 133941

[analyzer] Use UnknownVal when default-initializing arrays whose element types we don't model, to distinguish them from uninitialized arrays (PR10163).

llvm-svn: 133937

llvm-svn: 133931

If we cannot find the static library, use the dylib instead.

llvm-svn: 133926

for the '(' and ')' around the initializer unless we actually have an
initializer. Fixes PR10197, an issue where we were value-initializing
rather than default-initializing.

llvm-svn: 133913

a pointer to void.

llvm-svn: 133912

llvm-svn: 133911

of a single if block. This is really annoying to track down and test.
Silly changes to the test case caused it to stop showing up. I wish
there were a more concrete way of asserting that a note attaches to the
intended diagnostic.

This fixes PR10195.

llvm-svn: 133907

arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.

The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.

Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.

llvm-svn: 133906

Fix PR10187: when diagnosing a two-phase-lookup-related failure, don't assert that any names we find are valid candidates for the call.

llvm-svn: 133898

llvm-svn: 133864

When performing semantic analysis on a member declaration, fix the check for whether we are declaring a function to check for parenthesized declarators, declaration via decltype, etc.

Also fix the semantic check to not treat FuncType* as a function type.

llvm-svn: 133862

llvm-svn: 133861

by removing the redundant type parameter.

llvm-svn: 133860

arithmetic on a VLA as 'nsw', per discussion with djg, and
implement pointer arithmetic (other than array accesses) and
pointer subtraction for VLA types.

llvm-svn: 133855

declaration, determine whether the declaration will end up declaring a
function using semantic criteria (e.g., it will have function type)
rather than purely syntactic criteria (e.g., it has the form of a
function declarator). Fixes <rdar://problem/9670557>.

llvm-svn: 133854

to turn off warning on those properties which follow Cocoa naming
convention for retaining objects and yet they were not meant for
such purposes. Also, perform consistancy checking for declared
getters of such methods. // rdar://9636091

llvm-svn: 133849

in the variable to an inline asm which gets run when the variable
goes out of scope.

llvm-svn: 133840

Sorry, this was a bad idea.  Within clang these builtins are in a separate
"ARM" namespace, but the actual builtin names should clearly distinguish tha
they are target specific.

llvm-svn: 133833

llvm-svn: 133829

not sizes;  so that we use well-typed allocas;  and so that we
properly recurse through the full set of variably-modified types.

llvm-svn: 133827

llvm-svn: 133826

is not implemented. // rdar://9651605

llvm-svn: 133819

Fixes crash in http://llvm.org/PR10109 & rdar://9584039.

llvm-svn: 133816

objects.  // rdar://9495837

llvm-svn: 133806

if the location given points at the last token of the macro instantiation.

Fixes rdar://9045701.

llvm-svn: 133804

points to a macro instantiation.

llvm-svn: 133802

at the start of a macro instantiation.

llvm-svn: 133801

is at the first token but that the location's offset is not inside the token as well.

llvm-svn: 133800