| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch add a new option to dis-allow all inline asm.
Any GCC style inline asm will be reported as an error.
Reviewers: rnk, echristo
Reviewed By: rnk, echristo
Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D6870
llvm-svn: 226340
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in the previous commit, if a property (declared with @property)
has a name that matches a special Objective-C method family, the getter picks
up that family despite being declared by the property. The most correct way
to solve this problem is to add the 'objc_method_family' attribute to the
getter with an argument of 'none', which unfortunately requires an explicit
declaration of the getter.
This commit adds a note to the existing error (ARC) or warning (MRR) for
such a poorly-named property that suggests the solution; if there's already
a declaration of the getter, it even includes a fix-it.
llvm-svn: 226339
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two years ago I added a compile-time "optimization" to
ObjCMethodDecl::findPropertyDecl: exit early if the current method is part
of a special Objective-C method family (like 'new' or 'init'). However, if a
property (declared with @property) has a name that matches a method family,
the getter picks up that family despite being declared by the property. The
early exit then made ObjCMethodDecl::findPropertyDecl decide that there
was no associated property, despite the method itself being marked as an
accessor. This corrects that by removing the early exit.
This does /not/ change the fact that such a getter is considered to return a
value with a +1 retain count. The best way to eliminate this is by adding the
objc_method_family(none) attribute to the getter, but unlike the existing
ns_returns_not_retained that can't be applied directly to the property -- you
have to redeclare the getter instead.
(It'd be nice if @property just implied objc_method_family(none) for its
getter, but that would be a backwards-incompatible change.)
rdar://problem/19038838
llvm-svn: 226338
|
| |
|
|
|
|
|
|
|
|
|
| |
Emitting inlinable calls without debug locations (in functions with
debug info, to functions with debug info) is problematic for debug info
when inlining occurs. Test specifically that we don't do that in this
case - thus the test isn't simply "don't crash", it's "include debug
location for this call" (granted it's the wrong location - fix for that
is coming)
llvm-svn: 226337
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ambiguity but wasn't.
In the new test case, "click" wasn't being corrected properly because
Sema::ClassifyName would call CorrectTypo for "click" then later
Sema::DiagnoseEmptyLookup would call CorrectTypoDelayed for the same use
of "click" (the former by the parser needing to determine what the
identifier is so it knows how to parse the statement, i.e. is it the
beginning of a declaration or an expression). CorrectTypo would record
that typo correction for "click" failed and CorrectTypoDelayed would see
that and not even try to correct the typo, even though in this case
CorrectTypo failed due to an ambiguity (both "Click" and "clock" having
an edit distance of one from "click") that could be resolved with more
information. The fix is two-fold:
1) Have CorrectTypo not record failed corrections if the reason for
the failure was two or more corrections with the same edit
distance, and
2) Make the CorrectionCandidateCallback used by
Parser::ParseCastExpression reject FunctionDecl candidates when the
next token after the identifier is a ".", "=", or "->" since
functions cannot be assigned to and do not have members that can be
referenced.
The reason for two correction spots is that from r222549 until r224375
landed, the first correction attempt would fail completely but the
second would suggest "clock" while having the note point to the
declaration of "Click".
llvm-svn: 226334
|
| |
|
|
|
|
|
|
| |
at the same time.
Patch by David Callahan.
llvm-svn: 226331
|
| |
|
|
|
|
|
|
| |
Fixes PR22236
Patch by Nicolas Brunie! <nicolas.brunie@kalray.eu>
llvm-svn: 226328
|
| |
|
|
| |
llvm-svn: 226325
|
| |
|
|
| |
llvm-svn: 226320
|
| |
|
|
| |
llvm-svn: 226317
|
| |
|
|
| |
llvm-svn: 226307
|
| |
|
|
|
|
|
|
|
|
|
| |
There was already an explicit check for that for the first decl. Move that
to a different place so that it's called for the following decls too. Also
don't randomly set the BitfieldSize ExprResult to true (this sets a pointer to
true internally).
Found by SLi's bot.
llvm-svn: 226306
|
| |
|
|
| |
llvm-svn: 226303
|
| |
|
|
|
|
| |
Part of <rdar://problem/17688758>
llvm-svn: 226298
|
| |
|
|
| |
llvm-svn: 226297
|
| |
|
|
| |
llvm-svn: 226294
|
| |
|
|
| |
llvm-svn: 226286
|
| |
|
|
| |
llvm-svn: 226285
|
| |
|
|
| |
llvm-svn: 226282
|
| |
|
|
| |
llvm-svn: 226280
|
| |
|
|
|
|
| |
Correct logic concerning 'T &&' deduction against lvalues.
llvm-svn: 226278
|
| |
|
|
|
|
|
|
| |
storage.
This fix allows to use non-constant global variables, static local variables and static data
members in data-sharing attribute clauses in parallel and task regions.
llvm-svn: 226250
|
| |
|
|
|
|
|
|
|
| |
This produces comdats for vtables, typeinfo, typeinfo names, and vtts.
When combined with llvm not producing implicit comdats, not doing this would
cause code bloat on ELF and link errors on COFF.
llvm-svn: 226227
|
| |
|
|
|
|
|
| |
When combined with llvm not producing implicit comdats, not doing this would
cause code bloat on ELF and link errors on COFF.
llvm-svn: 226211
|
| |
|
|
|
|
|
|
| |
The PPC backend will now assume that PPC64 ELFv1 function descriptors are
invariant. This must be true for well-defined C/C++ code, but I'm providing an
option to disable this assumption in case someone's JIT-engine needs it.
llvm-svn: 226209
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR22035)
Clang would previously become confused and crash here.
It does not make a lot of sense to export these, so warning seems appropriate.
MSVC will export some member functions for this kind of specializations, whereas
MinGW ignores the dllexport-edness. The latter behaviour seems better.
Differential Revision: http://reviews.llvm.org/D6984
llvm-svn: 226208
|
| |
|
|
|
|
| |
reject CV void return type on C definitions per 6.9.1/3
llvm-svn: 226178
|
| |
|
|
|
|
|
|
|
|
| |
object from the pass that provides access to it.
We should probably refactor the createTLI code here in Clang in light of
the new structure, but I wanted this patch to be a minimal one that just
patches the behavior back together.
llvm-svn: 226158
|
| |
|
|
|
|
|
| |
Dependent alignment attributes should make an alignof expression
dependent as well.
llvm-svn: 226156
|
| |
|
|
|
|
| |
supplied by Analysis.
llvm-svn: 226152
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Types composed with certain implicit record types would have their RTTI
marked as hidden because the implicit record type didn't have any
visibility.
This manifests itself as triggering false positives from tools like
clang's -fsantize=function feature. The RTTI for a function type's
return type wouldn't match if the return type was an implicit record
type.
Patch by Stephan Bergmann!
llvm-svn: 226148
|
| |
|
|
| |
llvm-svn: 226142
|
| |
|
|
| |
llvm-svn: 226136
|
| |
|
|
| |
llvm-svn: 226135
|
| |
|
|
| |
llvm-svn: 226128
|
| |
|
|
|
|
|
|
|
|
|
| |
Sema calls HandleVTable() with a bool parameter which is then threaded through
three layers. The only effect of this bool is an early return at the last
layer.
Instead, remove this parameter and call HandleVTable() only if the bool is
true. No intended behavior change.
llvm-svn: 226096
|
| |
|
|
|
|
|
|
|
| |
prior visible declaration. Prefer to take template parameter names from the
first declaration.
Testcase from a patch by Francisco Lopes!
llvm-svn: 226083
|
| |
|
|
|
|
| |
Analysis library.
llvm-svn: 226079
|
| |
|
|
| |
llvm-svn: 226067
|
| |
|
|
|
|
| |
Update testcases to match LLVM change in r226048.
llvm-svn: 226049
|
| |
|
|
|
|
| |
This breaks green-dragon. Revert it and investigate.
llvm-svn: 226011
|
| |
|
|
| |
llvm-svn: 226010
|
| |
|
|
|
|
| |
The 3.6 release notes are in the 3.6 branch.
llvm-svn: 226009
|
| |
|
|
| |
llvm-svn: 226008
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a more robust way of figuring out implicit deployment target
from isysroot. It also handles iphone simulator target.
Reviewers: bob.wilson, t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, cfe-commits
Differential Revision: http://reviews.llvm.org/D6939
llvm-svn: 226005
|
| |
|
|
|
|
|
| |
Disable AlwaysBreakBeforeMultilineString, as the style guides don't
really say to do so.
llvm-svn: 225982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes MultiSource/Applications/lemon on big-endian N32 by correcting the
handling of the argument to wait(). glibc defines it as a transparent union of
void* and int*. Such unions are passed according to the rules of the first
member so the argument must be passed as if it were a void* (sign extended from
i32 to i64) and not as a union (shifted to the upper bits of an i64).
wait() already behaves correctly on big-endian O32 and N64 since the union is
already the same size as an argument slot.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6963
llvm-svn: 225981
|
| |
|
|
|
|
|
|
|
|
| |
Sorry for the noise, I managed to miss a bunch of recent regressions of
include orderings here. This should actually sort all the includes for
Clang. Again, no functionality changed, this is just a mechanical
cleanup that I try to run periodically to keep the #include lines as
regular as possible across the project.
llvm-svn: 225979
|
| |
|
|
|
|
|
| |
No functionality changed, this is a purely mechanical cleanup to ensure
the #include order remains consistent across the project.
llvm-svn: 225975
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
try
(SomeResource rs = someFunction()) {
Something();
}
After:
try (SomeResource rs = someFunction()) {
Something();
}
llvm-svn: 225973
|