Add support for .bind("foo") expressions on the dynamic matchers.

Summary: Add support on the parser, registry, and DynTypedMatcher for binding IDs dynamically.

Reviewers: klimek

CC: cfe-commits, revane

Differential Revision: http://llvm-reviews.chandlerc.com/D911

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183144 91177308-0d34-0410-b5e6-96231b3b80d8
__uint128_t is only available on 64 bit platforms, only test it when it's around.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183146 91177308-0d34-0410-b5e6-96231b3b80d8
UnresolvedMemberExpr should have an expr location of the member (not the base)

This matches the behavior of MemberExpr and makes diagnostics such as
"reference to non-static member function must be called" more legible in
the case that the base & member are split over multiple lines (prior to
this change the diagnostic would point to the base, not the member -
making it very unclear in chained multi-line builder-style calls)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183149 91177308-0d34-0410-b5e6-96231b3b80d8
Pacify compilers that think you can drop off a fully covered switch.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183155 91177308-0d34-0410-b5e6-96231b3b80d8
CFG: In a DeclStmt, skip anything that's not a VarDecl.

Neither the compiler nor the analyzer are doing anything with non-VarDecl
decls in the CFG, and having them there creates extra nodes in the
analyzer's path diagnostics. Simplify the CFG (and the path edges) by
simply leaving them out. We can always add interesting decls back in when
they become relevant.

Note that this only affects decls declared in a DeclStmt, and then only
those that appear within a function body.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183157 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer; new edges] Include a top-level function entry edge while optimizing.

Although we don't want to show a function entry edge for a top-level path,
having it makes optimizing edges a little more uniform.

This does not affect any edges now, but will affect context edge generation
(next commit).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183158 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer; new edges] Include context for edges to sub-expressions.

The current edge-generation algorithm sometimes creates edges from a
top-level statement A to a sub-expression B.1 that's not at the start of B.
This creates a "swoosh" effect where the arrow is drawn on top of the
text at the start of B. In these cases, the results are clearer if we see
an edge from A to B, then another one from B to B.1.

Admittedly, this does create a /lot/ of arrows, some of which merely hop
into a subexpression and then out again for a single note. The next commit
will eliminate these if the subexpression is simple enough.

This updates and reuses some of the infrastructure from the old edge-
generation algorithm to find the "enclosing statement" context for a
given expression. One change in particular marks the context of the
LHS or RHS of a logical binary operator (&&, ||) as the entire operator
expression, rather than the subexpression itself. This matches our behavior
for ?:, and allows us to handle nested context information.

<rdar://problem/13902816>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183159 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer; new edges] Improve enclosing contexts for logical expressions.

The old edge builder didn't have a notion of nested statement contexts,
so there was no special treatment of a logical operator inside an if
(or inside another logical operator). The new edge builder always tries
to establish the full context up to the top-level statement, so it's
important to know how much context has been established already rather
than just checking the innermost context.

This restores some of the old behavior for the old edge generation:
the context of a logical operator's non-controlling expression is the
subexpression in the old edge algorithm, but the entire operator
expression in the new algorithm.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183160 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer; new edges] Extra test case.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183161 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer; new edges] Eliminate "cycle edges" for a single subexpression.

Generating context arrows can result in quite a few arrows surrounding a
relatively simple expression, often containing only a single path note.

|
1 +--2---+
v/       v
auto m = new m // 3 (the path note)
|\       |
5 +--4---+
v

Note also that 5 and 1 are two ends of the "same" arrow, i.e. they go from
event to event. 3 is not an arrow but the path note itself.

Now, if we see a pair of edges like 2 and 4---where 4 is the reverse of 2
and there is optionally a single path note between them---we will
eliminate /both/ edges. Anything more complicated will be left as is
(more edges involved, an inlined call, etc).

The next commit will refine this to preserve the arrows in a larger
expression, so that we don't lose all context.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183162 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer; new edges] Don't eliminate subexpr edge cycles if the line is long.

Specifically, if the line is over 80 characters, or if the top-level
statement spans mulitple lines, we should preserve sub-expression edges
even if they form a simple cycle as described in the last commit, because
it's harder to infer what's going on than it is for shorter lines.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183163 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer; new edges] Omit subexpression back-edges that span multiple lines.

A.1 -> A -> B
becomes
A.1 -> B

This only applies if there's an edge from a subexpression to its parent
expression, and that is immediately followed by another edge from the
parent expression to a subsequent expression. Normally this is useful for
bringing the edges back to the left side of the code, but when the
subexpression is on a different line the backedge ends up looking strange,
and may even obscure code. In these cases, it's better to just continue
to the next top-level statement.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183164 91177308-0d34-0410-b5e6-96231b3b80d8
[analyzer] Enable the new edge algorithm by default.

...but don't yet migrate over the existing plist tests. Some of these
would be trivial to migrate; others could use a bit of inspection first.
In any case, though, the new edge algorithm seems to have proven itself,
and we'd like more coverage (and more usage) of it going forwards.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183165 91177308-0d34-0410-b5e6-96231b3b80d8
Do not report -Wasm-operand-widths for ARM output operands. <rdar://14050337>

We're getting reports of this warning getting triggered in cases where it
is not adding any value. There is no asm operand modifier that you can use
to silence it, and there's really nothing wrong with having an LDRB, for
example, with a "char" output.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183172 91177308-0d34-0410-b5e6-96231b3b80d8
Bound member function diagnostic - suggest no-args calls and note overload candidates

Still missing cases for templates, but this is a step in the right
direction. Also omits suggestions that would be ambiguous (eg: void
func(int = 0); + void func(float = 0); func;)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183173 91177308-0d34-0410-b5e6-96231b3b80d8
Adding support for MSVC #pragma detect_mismatch functionality by emitting a FAILIFMISMATCH linker command into the object file.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183178 91177308-0d34-0410-b5e6-96231b3b80d8
Remove some unreachable (and wrong) code and replace it with an assertion.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183206 91177308-0d34-0410-b5e6-96231b3b80d8
Rephrase asm_mismatched_size_modifier diagnostic. <rdar://problem/14050339>

The text of this diagnostic was unnecessarily specific to the current ARM
implementation of validateConstraintModifier, and it gave a potentially
confusing suggestion for fixing the problem. The ARM-specific issue is not
a big deal since that is the only target that currently does any checking of
asm operand modifiers, but until my change in 183172 it was still wrong for
output operands in the way that it referred to the value being truncated when
put into a register, since output operands are retrieved from the registers
instead of being put into them. The bigger problem is that its suggestion to
"use a modifier" is wrong and confusing in the case where a "q" modifier is
incorrectly used with an "r" constraint. In that case, the solution might
well be to remove the modifier or perhaps change the constraint. It's better
to just leave the diagnostic message more generic.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183209 91177308-0d34-0410-b5e6-96231b3b80d8
Reset the release notes for the 3.4 release.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183211 91177308-0d34-0410-b5e6-96231b3b80d8
Fix typo in comment. Found by -Wdocumentation.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183217 91177308-0d34-0410-b5e6-96231b3b80d8