reference is going to message the setter, the getter, or both.

Having this info on the ObjCPropertyRefExpr node makes it easier for AST
clients (like libclang) to reason about the meaning of the property reference.

[AST/Sema]
-Use 2 bits (with a PointerIntPair) in ObjCPropertyRefExpr to record the above info
-Have ObjCPropertyOpBuilder set the info appropriately.

[libclang]
-When there is an implicit property reference (property syntax using methods)
have clang_getCursorReferenced return a cursor for the method. If the property
reference is going to result in messaging both the getter and the setter choose
to return a cursor for the setter because it is less obvious from source inspection
that the setter is getting called.

The general idea has the seal of approval by John.

rdar://11151621

llvm-svn: 153709

Extend -Wc++11-narrowing to cover converted constant expressions as well as braced-initializers.  <rdar://problem/11121178>.

llvm-svn: 153703

llvm-svn: 153698

llvm-svn: 153678

llvm-svn: 153674

llvm-svn: 153673

LLVM intrinsics for.

I have an implementation of these functions, which wants to go in a libgcc_s
equivalent in compiler-rt.  It's currently here:

http://people.freebsd.org/~theraven/atomic.c

It will be committed to compiler-rt as soon as I work out where would be a
sensible place to put it...

llvm-svn: 153666

llvm-svn: 153665

visibility directives for a variety of exported
meta-data symbols. // rdar://11144048

llvm-svn: 153663

llvm-svn: 153660

in the property debug info. Any more isn't necessary after all.

rdar://11144023

llvm-svn: 153659

llvm-svn: 153658

llvm-svn: 153648

    http://llvm.org/docs/SourceLevelDebugging.html#objcproperty

    including type and DECL. Expand the getter and setter names
    into the fully qualified names.

    rdar://11144023

llvm-svn: 153640

with libunwind installed.
Patch by Jeffrey Yasskin!

llvm-svn: 153633

diagnostic and a fix-it to explain to the user where the ellipsis is
supposed to go.

llvm-svn: 153622

in the interface, got its attribute rewritten twice, resulting in
'weakweak' or 'strongstrong'.

rdar://11047179

llvm-svn: 153621

Add a test for this too.

llvm-svn: 153616

a complete object, the memcpy needs to use the data size of
the structure instead of its sizeof() value.  Fixes PR12204.

llvm-svn: 153613

llvm-svn: 153591

Patch by Dmitri Shubin!

llvm-svn: 153585

provide 'fixit' hint when dictionary index 
is not of proper type. // rdar://11062080

llvm-svn: 153584

retry without inlining.

(+ other minor cleanups)

llvm-svn: 153581

the root function.

(This is a bit cleaner then using the StackFrame.)

llvm-svn: 153580

llvm-svn: 153578

concerning qualified declarator-ids. We now diagnose extraneous
qualification at namespace scope (which we had previously missed) and
diagnose these qualification errors for all kinds of declarations; it
was rather uneven before. Fixes <rdar://problem/11135644>.

llvm-svn: 153577

search for the specialization (in a folding set) and, if not found
form a *Decl that is then inserted into that folding set. In rare
cases, the folding set may be reallocated between the search and the
insertion, causing a crash. No test case, because triggering rehashing
consistently in a small test case is not feasible. Fixes
<rdar://problem/11115071>.

llvm-svn: 153575

llvm-svn: 153568

flag as GCC uses: -fstrict-enums). There is a *lot* of code making
unwarranted assumptions about the underlying type of enums, and it
doesn't seem entirely reasonable to eagerly break all of it.

Much more importantly, the current state of affairs is *very* good at
optimizing based upon this information, which causes failures that are
very distant from the actual enum. Before we push for enabling this by
default, I think we need to implement -fcatch-undefined-behavior support
for instrumenting and trapping whenever we store or load a value outside
of the range. That way we can track down the misbehaving code very
quickly.

I discussed this with Rafael, and currently the only important cases he
is aware of are the bool range-based optimizations which are staying
hard enabled. We've not seen any issue with those either, and they are
much more important for performance.

llvm-svn: 153550

completion item. For example, if the code completion itself represents
a declaration in a namespace (say, std::vector), then this API
retrieves the cursor kind and name of the namespace (std). Implements
<rdar://problem/11121951>.

llvm-svn: 153545

necessarily mean we've found a function declarator. If the next token is not
a ')', this is actually a parenthesized pack expansion.

llvm-svn: 153544

// rdar://11124775

llvm-svn: 153535

The analyzer gives up path exploration under certain conditions. For
example, when the same basic block has been visited more than 4 times.
With inlining turned on, this could lead to decrease in code coverage.
Specifically, if we give up inside the inlined function, the rest of
parent's basic blocks will not get analyzed.

This commit introduces an option to enable re-run along the failed path,
in which we do not inline the last inlined call site. This is done by
enqueueing the node before the processing of the inlined call site
with a special policy encoded in the state. The policy tells us not to
inline the call site along the path.

This lead to ~10% increase in the number of paths analyzed. Even though
we expected a much greater coverage improvement. 

The option is turned off by default for now.

llvm-svn: 153534

Report root function name with exhausted block diagnostic.

Also, use stack frames, not just any location context when checking if
the basic block is in the same context.

llvm-svn: 153532

analyzes.

(This method can be called twice on the same function.)

llvm-svn: 153531

Patch by Jack Carter.

llvm-svn: 153530

"#include MACRO(STUFF)".

-As an inclusion position for the included file, use the file location of the file where it
was included but *after* the macro expansions. We want the macro expansions to be considered
as before-in-translation-unit for everything in the included file.

-In the preprocessing record take into account that only inclusion directives can be encountered
as "out-of-order" (by comparing the start of the range which for inclusions is the hash location)
and use binary search if there is an extreme number of macro expansions in the include directive.

Fixes rdar://11111779

llvm-svn: 153527

// rdar://11124354

llvm-svn: 153526

llvm-svn: 153523

list of identifiers that that 'public' names at the end of the
translation unit, e.g., defined macros or identifiers with top-level
names, in sorted order. Meant to support <rdar://problem/10921596>.

llvm-svn: 153522