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

llvm-svn: 134006

llvm-svn: 133994

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

llvm-svn: 133983

llvm-svn: 133971

// 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: 133957

Cache the result of AttributeList::getKind(); it's relatively expensive to compute, and we query it frequently enough that it showed up in a profile.

llvm-svn: 133948

llvm-svn: 133943

llvm-svn: 133942

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: 133934

llvm-svn: 133931

when the expression source range overlaps the declaration range.

This can happen for C++ constructor expressions whose range generally
include the variable declaration, e.g.:

  MyCXXClass foo; // Make sure pointing at 'foo' returns a VarDecl cursor.

rdar://9124499.

llvm-svn: 133930

variable declaration that it belongs to.

This can happen for C++ constructor expressions whose range generally
include the variable declaration, e.g.:

  MyCXXClass foo; // Make sure we don't annotate 'foo' as a CallExpr cursor.

rdar://9124499.

llvm-svn: 133929

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

llvm-svn: 133926

down to 8 by restricting the maximum allowed regparm value to 6
(previously it was 7). I need the extra bit in Type to handle
instantiation-dependence.

llvm-svn: 133924

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

llvm-svn: 133842