| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
through it, so we should look through it for the live-values
analysis as well.
llvm-svn: 144190
|
| |
|
|
| |
llvm-svn: 144189
|
| |
|
|
| |
llvm-svn: 144168
|
| |
|
|
|
|
|
| |
the other helper functions, since we already differentiated the cases it was
testing between. No functionality change.
llvm-svn: 144167
|
| |
|
|
|
|
|
|
|
|
|
|
| |
version of Ubuntu. It has a very broken multiarch configuration, and so
we need special logic to handle it correctly. Fixing and testing this
uncovered a few other trivial issues with the logic that are fixed as
well.
I added tests to cover this as it is hard to notice if you install
recent versions of the OS.
llvm-svn: 144165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block-typed __block variables using objc_retainBlock
and objc_dispose. Previously we were using
_Block_object_assign and _Block_object_destroy
with BLOCK_BYREF_CALLER, which causes the runtime
to completely ignore the retain and release.
In most cases this doesn't cause catastrophe
because the retain/release are balanced and
because the block in the variable was copied
upon assignment there. However, the stack
copy of the variable will be released when
it goes out of scope, which is a problem if
that value was released due to an assignment
to the heap copy. Similarly, a leak can occur
if the variable is assigned after the copy to
the heap.
llvm-svn: 144162
|
| |
|
|
|
|
| |
expression. Fixes PR11339.
llvm-svn: 144159
|
| |
|
|
|
|
| |
(bycopy, inout, etc.). Fixes <rdar://problem/10402900>.
llvm-svn: 144157
|
| |
|
|
| |
llvm-svn: 144156
|
| |
|
|
|
|
|
|
|
|
|
| |
In certain cases ASTReader would call the normal DiagnosticsEngine API to initialize
the state of diagnostic pragmas but DiagnosticsEngine would try to compare source locations
leading to crash because the main FileID was not yet initialized.
Yet another case of the ASTReader trying to use the normal APIs and inadvertently breaking
invariants. Fix this by having the ASTReader set up the internal state directly.
llvm-svn: 144153
|
| |
|
|
| |
llvm-svn: 144150
|
| |
|
|
|
|
| |
fix the test.
llvm-svn: 144146
|
| |
|
|
|
|
| |
opaque values. Silly C type system.
llvm-svn: 144144
|
| |
|
|
|
|
| |
// rdar://10415026
llvm-svn: 144143
|
| |
|
|
|
|
| |
redundant 'strong'.
llvm-svn: 144136
|
| |
|
|
|
|
| |
type is strong by default too. // rdar://10410903
llvm-svn: 144118
|
| |
|
|
| |
llvm-svn: 144115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Analysis by Ted:
"
if (stateZero && !stateNotZero) {
is checking to see if:
(A) "it is possible for the value to be zero" (stateZero)
AND
(B) "it is not possible for the value to be non-zero" (!stateNotZero)
That said, the only way for both B to be true AND A to be false is if the path is completely infeasible by the time we reach the divide-by-zero check. For the most part (all cases?), such cases should automatically get pruned out at branches (i.e., an infeasible path gets dropped), which is the case in our tests. So the question is whether or not such an infeasible path might not get dropped earlier? I can't envision any right now.
Indeed, the rest of the checker assumes that if the bug condition didn't fire then 'stateNotZero' is non-NULL:
C.addTransition(stateNotZero);
"
llvm-svn: 144114
|
| |
|
|
|
|
|
|
|
| |
which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.
llvm-svn: 144110
|
| |
|
|
| |
llvm-svn: 144108
|
| |
|
|
| |
llvm-svn: 144094
|
| |
|
|
|
|
|
|
|
|
|
|
| |
useful when using Clang as a system-compiler, but its harmless. When
using Clang as a cross-compiler, this can be very handy as quite a few
toolchains ship their libc headers here rather than under
'/usr/include'.
For reference, this is the beginning of my work to also make the Clang
driver more suitable as a cross-compiler.
llvm-svn: 144089
|
| |
|
|
|
|
|
|
| |
'(strong)'
property attribute.
llvm-svn: 144078
|
| |
|
|
| |
llvm-svn: 144077
|
| |
|
|
|
|
|
|
|
|
|
| |
The Neon load/store intrinsics need to be implemented as macros to avoid
hiding alignment attributes on the pointer arguments, and the macros can
only evaluate those pointer arguments once (in case they have side effects),
so it has been hard to get the right type checking for those pointers.
I tried various alternatives in the arm_neon.h header, but it's much more
straightforward to just check directly in Sema.
llvm-svn: 144075
|
| |
|
|
| |
llvm-svn: 144073
|
| |
|
|
|
|
| |
Based on work by Dmitry Sokolov!
llvm-svn: 144072
|
| |
|
|
| |
llvm-svn: 144065
|
| |
|
|
|
|
| |
Membarth, test case by myself.
llvm-svn: 144063
|
| |
|
|
|
|
|
|
|
| |
written, instead of the resolved storage class, which might not be
legal to specify on the declaration (such as out-of-line definitions
of static class members in C++, and __local variables in OpenCL).
Initial patch by Richard Membarth.
llvm-svn: 144062
|
| |
|
|
|
|
|
|
| |
__unsafe_unretained
later on, or we will end up with a redundant '__unsafe_unretained'.
llvm-svn: 144059
|
| |
|
|
|
|
| |
(TIL: -Wnon-virtual-dtor is not in -Wall.)
llvm-svn: 144058
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression evaluation:
- When folding a non-value-dependent expression, we may try to use the
initializer of a value-dependent variable. If that happens, give up.
- In C++98, actually check that a const, non-volatile DeclRefExpr inside an ICE
is of integral or enumeration type (a reference isn't OK!)
- In C++11, DeclRefExprs for objects of const literal type initialized with
value-dependent expressions are themselves value-dependent.
- So are references initialized with value-dependent expressions (though this
case is missing from the C++11 standard, along with many others).
llvm-svn: 144056
|
| |
|
|
|
|
|
|
|
| |
This patch just adds a simple NeonTypeFlags class to replace the various
hardcoded constants that had been used until now. Unfortunately I couldn't
figure out a good way to avoid duplicating that class between clang and
TableGen, but since it's small and rarely changes, that's not so bad.
llvm-svn: 144054
|
| |
|
|
|
|
|
|
|
| |
doesn't duplicate, but they all surface as implicit
properties. It's also a useful optimization to not
duplicate the implicit getter lookup. So, trust the
getter lookup that was already done in these cases.
llvm-svn: 144031
|
| |
|
|
|
|
|
|
| |
initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.
llvm-svn: 144028
|
| |
|
|
|
|
|
|
|
|
|
|
| |
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
llvm-svn: 144011
|
| |
|
|
| |
llvm-svn: 144002
|
| |
|
|
| |
llvm-svn: 144001
|
| |
|
|
|
|
| |
function template instantiations. Fixes <rdar://problem/10398005> / PR11312.
llvm-svn: 143984
|
| |
|
|
| |
llvm-svn: 143980
|
| |
|
|
|
|
|
|
|
| |
-Move __strong/__weak added to a property type to the property attribute,
e.g. "@property (assign) __weak Foo *prop;" --> "@property (weak) Foo *prop;"
-Remove (assign) in a property so that it becomes strong-by-default in ARC.
llvm-svn: 143979
|
| |
|
|
| |
llvm-svn: 143978
|
| |
|
|
|
|
|
|
| |
__int128_t and __uint128_t. Short and unsigned short integer literals support
is only to work around a crasher as reported in PR11179 and will be removed
once Clang no longer builds short integer literals.
llvm-svn: 143977
|
| |
|
|
|
|
| |
to objects of classes that don't support ARC weak
llvm-svn: 143976
|
| |
|
|
|
|
|
|
|
| |
__weak is unsupported by the deployment target, since it is going to be
ignored anyway.
Makes it easier for incremental migration from GC.
llvm-svn: 143975
|
| |
|
|
| |
llvm-svn: 143972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the injected-class-name of a class (or class template) to the
declaration that results from substituting the given template
arguments. Previously, we would actually perform a substitution into
the injected-class-name type and then retrieve the resulting
declaration. However, in certain, rare circumstances involving
deeply-nested member templates, we would get the wrong substitution
arguments.
This new approach just matches up the declaration with a declaration
that's part of the current context (or one of its parents), which will
either be an instantiation (during template instantiation) or the
declaration itself (during the definition of the template). This is
both more efficient (we're avoiding a substitution) and more correct
(we can't get the template arguments wrong in the member-template
case).
Fixes <rdar://problem/9676205>.
Reinstated, now that we have the fix in r143967.
llvm-svn: 143968
|
| |
|
|
|
|
|
| |
entering the context of a nested-name-specifier. Fixes
<rdar://problem/10397846>.
llvm-svn: 143967
|
| |
|
|
| |
llvm-svn: 143965
|