| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
We now check a few methods for UIResponder, NSResponder, and NSDocument.
Patch by Julian Mayer!
llvm-svn: 170089
|
| |
|
|
|
|
| |
and make sure additional uses don't get introduced. <rdar://problem/12858424>.
llvm-svn: 170081
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a Band-Aid fix to a false positive, where we complain about not
initializing self to [super init], where self is not coming from the
init method, but is coming from the caller to init.
The proper solution would be to associate the self and it's state with
the enclosing init.
llvm-svn: 170059
|
| |
|
|
|
|
| |
to (SEL). Fixes // rdar://12859590
llvm-svn: 170058
|
| |
|
|
|
|
| |
<rdar://problem/12857416>.
llvm-svn: 170056
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This still isn't quite right, but it fixes a crash.
I factored out findCommonParent because we need it on the result of
getImmediateExpansionRange: for a function macro, the beginning
and end of an expansion range can come out of different
macros/macro arguments, which means the resulting range is a complete
mess to handle consistently.
I also made some changes to how findCommonParent works; it works somewhat
better in some cases, and somewhat worse in others, but I think overall
it's a better balance. I'm coming to the conclusion that mapDiagnosticRanges
isn't using the right algorithm, though: chasing the caret is fundamentally
more complicated than any algorithm which only considers one FileID for the
caret can handle because each SourceLocation doesn't really have a single parent.
We need to follow the same path of choosing expansion locations and spelling
locations which the caret used to come up with the correct range
in the general case.
Fixes <rdar://problem/12847524>.
llvm-svn: 170049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation
has inconsistent ownership with the backing ivar, point the error location to the
ivar.
Pointing to the ivar (instead of the @synthesize) is better since this is where a fix is needed.
Also provide the location of @synthesize via a note.
This also fixes the problem where an auto-synthesized property would emit an error without
any location.
llvm-svn: 170039
|
| |
|
|
| |
llvm-svn: 170038
|
| |
|
|
|
|
|
|
|
|
|
|
| |
My variadics patch, r169588, changed these calls to typically be
bitcasts rather than calls to a supposedly variadic function.
This totally subverted a hack where we intentionally dropped
excess arguments from such calls in order to appease the inliner
and a "warning" from the optimizer. This patch extends the hack
to also work with bitcasts, as well as teaching it to rewrite
invokes.
llvm-svn: 170034
|
| |
|
|
|
|
|
|
|
|
| |
We don't handle array destructors correctly yet, but we now apply the same
hack (explicitly destroy the first element, implicitly invalidate the rest)
for multidimensional arrays that we already use for linear arrays.
<rdar://problem/12858542>
llvm-svn: 170000
|
| |
|
|
|
|
|
|
|
|
| |
call sites as tail calls unconditionally. While it's theoretically true that
this is just an optimization, it's an optimization that we very much want to
happen even at -O0, or else ARC applications become substantially harder to
debug. See r169796 for the llvm/fast-isel side of things.
rdar://12553082
llvm-svn: 169996
|
| |
|
|
|
|
| |
function-like macro which isn't immediately followed by '('. FreeBSD's stdio.h #defines foo(x) to (foo)(x), apparently.
llvm-svn: 169960
|
| |
|
|
|
|
|
|
| |
even if the directive is inside a declaration.
Fixes rdar://11548788 & http://llvm.org/PR12970
llvm-svn: 169949
|
| |
|
|
| |
llvm-svn: 169947
|
| |
|
|
|
|
|
|
| |
to r169831.
"ansi-escape-sequences" is easy convenient to exclude win32. Please be patient.
llvm-svn: 169945
|
| |
|
|
| |
llvm-svn: 169923
|
| |
|
|
| |
llvm-svn: 169922
|
| |
|
|
|
|
| |
latter is rather a mess to type.
llvm-svn: 169919
|
| |
|
|
| |
llvm-svn: 169917
|
| |
|
|
|
|
|
|
|
|
|
| |
Add -fslp-vectorize (with -ftree-slp-vectorize as an alias for gcc compatibility)
to provide a way to enable the basic-block vectorization pass. This uses the same
acronym as gcc, superword-level parallelism (SLP), also common in the literature,
to refer to basic-block vectorization.
Nadav suggested this as a follow-up to the adding of -fvectorize.
llvm-svn: 169909
|
| |
|
|
|
|
|
| |
byref variable requires extended layout info. to prevent
a crash involving arrays declared __block. // rdar://12787751
llvm-svn: 169908
|
| |
|
|
|
|
| |
unavailable due to availability attributes. <rdar://problem/12798237>
llvm-svn: 169903
|
| |
|
|
|
|
|
| |
compatibility with gcc.
rdar://12839978
llvm-svn: 169888
|
| |
|
|
|
|
| |
rdar://12839978
llvm-svn: 169885
|
| |
|
|
|
|
| |
Sorry for my 3rd commit :(
llvm-svn: 169827
|
| |
|
|
|
|
| |
know "REQUIRES:" would match --check-prefix=S ...
llvm-svn: 169826
|
| |
|
|
|
|
|
|
| |
is not used.
It is not set at targetting cygming. See PR12920.
llvm-svn: 169824
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't want to relax all instructions in
$ clang -c test.s
since most users don't pass -O when using the driver to assemble.
On the other hand, -save-temps should not change the output unnecessary, so in
$ clang -c test.c -save-temps
we should relax all instructions.
llvm-svn: 169815
|
| |
|
|
|
|
|
|
|
| |
definition, rather than at the end of the definition of the set of nested
classes. We still defer checking of the user-specified exception specification
to the end of the nesting -- we can't check that until we've parsed the
in-class initializers for non-static data members.
llvm-svn: 169805
|
| |
|
|
|
|
|
|
|
| |
inlined.
Fixes a false positive that occurs if a user writes their own
initWithBytesNoCopy:freeWhenDone wrapper.
llvm-svn: 169795
|
| |
|
|
| |
llvm-svn: 169778
|
| |
|
|
| |
llvm-svn: 169768
|
| |
|
|
|
|
| |
Also, add the -S option.
llvm-svn: 169763
|
| |
|
|
|
|
| |
was #import'ed.
llvm-svn: 169761
|
| |
|
|
|
|
|
|
|
| |
pass.
This prevents the functions generated by that pass from using the red zone.
<rdar://problem/12843084>
llvm-svn: 169755
|
| |
|
|
| |
llvm-svn: 169743
|
| |
|
|
|
|
| |
This fixes PR14339.
llvm-svn: 169705
|
| |
|
|
| |
llvm-svn: 169696
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
both LE and BE targets.
AFAICT, Clang get's this correct for PPC64. I've compared it to GCC 4.8
output for PPC64 (thanks Roman!) and to my limited ability to read power
assembly, it looks functionally equivalent. It would be really good to
fill in the assertions on this test case for x86-32, PPC32, ARM, etc.,
but I've reached the limit of my time and energy... Hopefully other
folks can chip in as it would be good to have this in place to test any
subsequent changes.
To those who care about PPC64 performance, a side note: there is some
*obnoxiously* bad code generated for these test cases. It would be worth
someone's time to sit down and teach the PPC backend to pattern match
these IR constructs better. It appears that things like '(shr %foo,
<imm>)' turn into 'rldicl R, R, 64-<imm>, <imm>' or some such. They
don't even get combined with other 'rldicl' instructions *immediately
adjacent*. I'll add a couple of these patterns to the README, but
I think it would be better to look at all the patterns produced by this
and other bitfield access code, and systematically build up a collection
of patterns that efficiently reduce them to the minimal code.
llvm-svn: 169693
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was an egregious bug due to the several iterations of refactorings
that took place. Size no longer meant what it original did by the time
I finished, but this line of code never got updated. Unfortunately we
had essentially zero tests for this in the regression test suite. =[
I've added a PPC64 run over the bitfield test case I've been primarily
using. I'm still looking at adding more tests and making sure this is
the *correct* bitfield access code on PPC64 linux, but it looks pretty
close to me, and it is *worlds* better than before this patch as it no
longer asserts! =] More commits to follow with at least additional tests
and maybe more fixes.
Sorry for the long breakage due to this....
llvm-svn: 169691
|
| |
|
|
|
|
|
|
|
|
| |
array from a braced-init-list. There seems to be a core wording wart
here (it suggests we should be testing whether the elements of the init
list are implicitly convertible to the array element type, not whether
there is an implicit conversion sequence) but our prior behavior appears
to be a bug, not a deliberate effort to implement the standard as written.
llvm-svn: 169690
|
| |
|
|
|
|
| |
don't mark the function as invalid, since we suppress the error.
llvm-svn: 169689
|
| |
|
|
|
|
| |
of the file.
llvm-svn: 169688
|
| |
|
|
|
|
|
|
| |
fed into the diagnostic formatting machinery again.
Fixes PR14543.
llvm-svn: 169677
|
| |
|
|
|
|
|
|
| |
Linux too, as I think we inherited it from there. The ABI spec says 128-bit,
although I think SGI's compiler on IRIX may be the only thing ever to support
this.
llvm-svn: 169674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the cases where we can't determine whether special members would be trivial
while building the class, we eagerly declare those special members. The impact
of this is bounded, since it does not trigger implicit declarations of special
members in classes which merely *use* those classes.
In order to determine whether we need to apply this rule, we also need to
eagerly declare move operations and destructors in cases where they might be
deleted. If a move operation were supposed to be deleted, it would instead
be suppressed, and we could need overload resolution to determine if we fall
back to a trivial copy operation. If a destructor were implicitly deleted,
it would cause the move constructor of any derived classes to be suppressed.
As discussed on cxx-abi-dev, C++11's selected constructor rules are also
retroactively applied as a defect resolution in C++03 mode, in order to
identify that class B has a non-trivial copy constructor (since it calls
A's constructor template, not A's copy constructor):
struct A { template<typename T> A(T &); };
struct B { mutable A a; };
llvm-svn: 169673
|
| |
|
|
| |
llvm-svn: 169669
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.
This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.
This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.
llvm-svn: 169667
|
| |
|
|
|
|
|
|
|
|
| |
directive as a macro expansion.
This is more of a "macro reference" than a macro expansion but it's close enough
for libclang's purposes. If it causes issues we can revisit and introduce a new
kind of cursor.
llvm-svn: 169666
|
| |
|
|
|
|
|
|
| |
properly, rather than faking it up by pretending that a reference member makes
the default constructor non-trivial. That leads to rejects-valids when putting
such types inside unions.
llvm-svn: 169662
|