| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
in duplicate -Wuninitialized warnings. Change so that only the check in
TryConstructorInitialization() will be used and a single warning be emitted.
llvm-svn: 161345
|
| |
|
|
|
|
| |
change intended. No test case as there's no real way to test at this time.
llvm-svn: 161342
|
| |
|
|
|
|
|
| |
we know whether the function is virtual. But check it as soon as we do know;
in some cases we don't need to wait for an instantiation.
llvm-svn: 161316
|
| |
|
|
|
|
| |
been defined.
llvm-svn: 161315
|
| |
|
|
| |
llvm-svn: 161303
|
| |
|
|
|
|
| |
non-type template parameter pack. Patch by Andy Gibbs!
llvm-svn: 161260
|
| |
|
|
| |
llvm-svn: 161245
|
| |
|
|
| |
llvm-svn: 161211
|
| |
|
|
|
|
|
| |
objects used as dictionary subscript objects.
// rdar://11913153
llvm-svn: 161187
|
| |
|
|
|
|
| |
-dealloc method. PR13401.
llvm-svn: 161135
|
| |
|
|
| |
llvm-svn: 161088
|
| |
|
|
|
|
|
|
|
|
| |
The only caveat is renumbering CXCommentKind enum for aesthetic reasons -- this
breaks libclang binary compatibility, but should not be a problem since API is
so new.
This also fixes PR13372 as a side-effect.
llvm-svn: 161087
|
| |
|
|
|
|
| |
sure to supply an initialization location. Fixes <rdar://problem/11951661>.
llvm-svn: 161084
|
| |
|
|
| |
llvm-svn: 161036
|
| |
|
|
|
|
|
|
| |
on object pointers and whether pointer arithmetic on object pointers
is supported. Make ObjFW interpret subscripts as pseudo-objects.
Based on a patch by Jonathan Schleifer.
llvm-svn: 161028
|
| |
|
|
|
|
|
|
|
|
| |
type and then propagated to the function. This was failing for destructors,
constructors and constructors templates since they don't have a return type.
Fix that by directly calling processTypeAttrs on the dummy type we use as the
return type in these cases.
llvm-svn: 161020
|
| |
|
|
|
|
|
| |
This is just a clarification on Fariborz's original patch, per e-mail
discussion. No functionality change.
llvm-svn: 161016
|
| |
|
|
|
|
|
|
| |
sure to update the exception specification on the declaration as well as the
definition. If we're building in -fno-exceptions mode, nothing else will
trigger it to be updated.
llvm-svn: 161008
|
| |
|
|
|
|
| |
with-arguments case as well as the no-arguments case.
llvm-svn: 160999
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.
Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.
llvm-svn: 160998
|
| |
|
|
|
|
|
|
|
|
| |
type of generated call to super dealloc is 'void'
and asserts if user's dealloc is not of 'void type.
This rule must be enforced in clang front-end (with a
fixit) if this is not the case, instead of asserting in CodeGen.
// rdar://11987838
llvm-svn: 160993
|
| |
|
|
|
|
|
|
| |
While '%n' can be used for evil in an attacker-controlled format string, there
isn't any acute danger in using it in a literal format string with an argument
of the appropriate type.
llvm-svn: 160984
|
| |
|
|
|
|
|
| |
This makes Clang check that the corresponding argument for "%n" in a
format string is a pointer to int.
llvm-svn: 160966
|
| |
|
|
|
|
| |
nontrivial because of it.
llvm-svn: 160962
|
| |
|
|
|
|
|
|
|
| |
expressions to have complete return types (or accessible destructors). If the
return type is required to be complete for some other reason (for instance, if
it is needed by overload resolution), then it will still be required to be
complete. This is apparently required in order to parse a MSVC11 header.
llvm-svn: 160924
|
| |
|
|
|
|
| |
CF to ARC conversions.
llvm-svn: 160923
|
| |
|
|
|
|
|
| |
__bride fixit, as it doesn't matter which cast to
use. // rdar://11923822
llvm-svn: 160906
|
| |
|
|
|
|
| |
// rdar://11923822
llvm-svn: 160902
|
| |
|
|
|
|
|
|
| |
are cast to retainable types, only suggest CFBridgingRelease/
CFBridgingRetain and not the __bridge casts.
// rdar://11923822
llvm-svn: 160900
|
| |
|
|
| |
llvm-svn: 160895
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.
Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.
llvm-svn: 160885
|
| |
|
|
|
|
| |
sure we always have the right end.
llvm-svn: 160855
|
| |
|
|
| |
llvm-svn: 160851
|
| |
|
|
| |
llvm-svn: 160850
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
|
| |
|
|
|
|
|
|
| |
retainable types in arc, only suggest CFBridgingRelease/
CFBridgingRetain and not the confusing __bridge casts.
// rdar://11923822
llvm-svn: 160839
|
| |
|
|
|
|
| |
testcase.
llvm-svn: 160766
|
| |
|
|
|
|
|
|
|
|
| |
Rather than adding a ContainsUnexpandedParameterPack bit to essentially every
AST node, we tunnel the bit directly up to the surrounding lambda expression
when we reach a context where an unexpanded pack can not normally appear.
Thus any statement or declaration within a lambda can now potentially contain
an unexpanded parameter pack.
llvm-svn: 160705
|
| |
|
|
|
|
| |
unless they appear in a decl-specifier-seq.
llvm-svn: 160688
|
| |
|
|
|
|
|
|
|
|
| |
A warning was added in r150128 for returning non-C compatible
user-defined types from functions with C linkage.
This makes the text more clear for the case when the type isn't
decidedly non-C compatible, but incomplete.
llvm-svn: 160681
|
| |
|
|
|
|
|
| |
variables that have static storage duration, it removes debug info on the
emitted initializer function but not all debug info about this variable.
llvm-svn: 160659
|
| |
|
|
| |
llvm-svn: 160658
|
| |
|
|
| |
llvm-svn: 160657
|
| |
|
|
|
|
| |
APSInt::isSameValue() when comparing different sized APSInt's.
llvm-svn: 160641
|
| |
|
|
|
|
|
|
| |
Make handler functions for thread safety attributes consistent with other attributes handler functions
by removing the bool parameter from some of the thread safety attributes handler functions and extracting
common checks out of different handler functions.
llvm-svn: 160635
|
| |
|
|
| |
llvm-svn: 160622
|
| |
|
|
|
|
|
|
| |
structor class under ARC, that struct/class does not have a trivial
move constructor or move assignment operator. Fixes the rest of
<rdar://problem/11738725>.
llvm-svn: 160615
|
| |
|
|
|
|
|
|
|
|
| |
change once it's been assigned. It can change in two ways:
1) In a template instantiation, the context declaration should be the
instantiated declaration, not the declaration in the template.
2) If a lambda appears in the pattern of a variadic pack expansion, the
mangling number will depend on the pack length.
llvm-svn: 160614
|
| |
|
|
|
|
| |
number of formal parameters for a variadic function call.
llvm-svn: 160570
|
| |
|
|
|
|
|
|
| |
or implementation since we've now got a different layout.
Fixes rdar://11842763
llvm-svn: 160526
|