Template functions (and member functions of class templates) present the same
problem as inline functions. They need to be uniqued, so we need to assign
VisibleNoLinkage linkage to types defined in them.
llvm-svn: 183222
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.
llvm-svn: 183209
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;)
llvm-svn: 183173
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.
llvm-svn: 183172
...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.
llvm-svn: 183165
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.
llvm-svn: 183164
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.
llvm-svn: 183163
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.
llvm-svn: 183162
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.
llvm-svn: 183160
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>
llvm-svn: 183159
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.
llvm-svn: 183157
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)
llvm-svn: 183149
which is lifetime-extended by a reference binding. An additional temporary is
created for such a bitfield access (although we have no explicit AST
representation for it).
llvm-svn: 183095
materialized temporary with the corresponding MaterializeTemporaryExpr. This is
groundwork for providing C++11's guaranteed static initialization for global
references bound to lifetime-extended temporaries (if the initialization is a
constant expression).
In passing, fix a couple of bugs where some evaluation failures didn't trigger
diagnostics, and a rejects-valid where potential constant expression testing
would assume that it knew the dynamic type of *this and would reject programs
which relied on it being some derived type.
llvm-svn: 183093
clang would incorrectly not allow the following:
int x = true ? (throw 1) : 2;
The problem exists because we don't see beyond the parens.
This, in turn, causes us to believe that we are choosing between void
and int which we diagnose as an error.
Instead, allow clang to see the 'throw' inside the parens.
llvm-svn: 183085
In some cases, clang applies the C++ rules for computing the range of a
value when said value is an enum.
Instead, apply C semantics when in C mode.
llvm-svn: 183084
Jordan has pointed out that it is valuable to warn in cases when the arguments to init escape.
For example, NSData initWithBytes id not going to free the memory.
llvm-svn: 183062
For integer types of sizes 1, 2, 4 and 8, libcompiler-rt (and libgcc)
provide atomic functions that pass parameters by value and return
results directly.
libgcc and libcompiler-rt only provide optimized libcalls for
__atomic_fetch_*, as generic libcalls on non-integer types would make
little sense. This means that we can finally make __atomic_fetch_* work
on architectures for which we don't provide these operations as builtins
(e.g. ARM).
This should fix the dreaded "cannot compile this atomic library call
yet" error that would pop up once every while.
llvm-svn: 183033
In many cases, the edge from the "if" to the condition, followed by an edge from the branch condition to the target code, is uninteresting.
In such cases, we should fold the two edges into one from the "if" to the target.
This also applies to loops.
Implements <rdar://problem/14034763>.
llvm-svn: 183018
In a certain code-path we were not deserializing an anonymous field initializer correctly,
leading to a crash when trying to IRGen it.
This is a simpler version of a patch by Yunzhong Gao!
llvm-svn: 182974
syntactic form in template instantiation. Previously, this blocked the
reversion and we ended up losing inner CXXBindTemporaryExprs (and thus
forgetting to call destructors!).
llvm-svn: 182969
...and make this work correctly in the current codebase.
After living on this for a while, it turns out to look very strange for
inlined functions that have only a single statement, and somewhat strange
for inlined functions in general (since they are still conceptually in the
middle of the path, and there is a function-entry path note).
It's worth noting that this only affects inlined functions; in the new
arrow generation algorithm, the top-level function still starts at the
first real statement in the function body, not the enclosing CompoundStmt.
This reverts r182078 / dbfa950abe0e55b173286a306ee620eff5f72ea.
llvm-svn: 182963
The testcase in PR16060 points out that while template arguments can
show that a type is not externally visible, the standards still says
they have external linkage.
In terms of our implementation, it means that we should merge just the
isExternallyVisible bit, not the formal linkage.
llvm-svn: 182962
Check for invalid decls in ObjCMethodDecl::getNextRedeclaration(); otherwise if we start from an invalid redeclaration
of an @implementation we would move to the @interface and not reach the original declaration again.
Fixes rdar://14024851
llvm-svn: 182951
It is okay to declare a block without an argument list: ^ {} or ^void {}.
In these cases, the BlockDecl's signature-as-written will just contain
the return type, rather than the entire function type. It is unclear if
this is intentional, but the analyzer shouldn't crash because of it.
<rdar://problem/14018351>
llvm-svn: 182948
references. What's more, they use this language extension in their
ATL header files (which come as part of MFC and the Win32 SDK). This patch implements support for the Microsoft extension, and addresses PR13737.
llvm-svn: 182936
Most loop notes (like "entering loop body") are attached to the condition
expression guarding a loop or its equivalent. For loops may not have a
condition expression, though. Rather than crashing, just use the entire
ForStmt as the location. This is probably the best we can do.
<rdar://problem/14016063>
llvm-svn: 182904
This change is motivated from user feedback that some APIs use
void* as an opaque "context" object that may not really be a pointer.
Such users want an ability to turn off the warning for casts
to void* while preserving the warning for other cases.
Implements <rdar://problem/14016721>.
llvm-svn: 182884
Rafael Espindola