Rather than simply saying "X is not a class or namespace", clarify what
X is by providing the aka type in the case where X is a type, or
pointing to the named declaration if there's an unambiguous one to refer
to. In the ambiguous case, the ambiguities are already enumerated
(though could be clarified by describing what kind of entities they are)
Included a few FIXMEs in tests where some further improvements could be
made.
llvm-svn: 201038
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
llvm-svn: 199250
The ABI requires the destructor to be invoked in the callee, but the
standard does not require access checks here so we avoid doing direct
access checks on the destructor.
If we end up needing to define an implicit destructor, we don't skip
access checks for the base class, etc. Those checks are effectively part
of generating the destructor definition, and aren't affected by which TU
the check is performed in.
Differential Revision: http://llvm-reviews.chandlerc.com/D2409
llvm-svn: 199120
Fixes <rdar://problem/15584219> and <rdar://problem/12241361>.
This change looks large, but all it does is reuse and consolidate
the delayed diagnostic logic for deprecation warnings with unavailability
warnings. By doing so, it showed various inconsistencies between the
diagnostics, which were close, but not consistent. It also revealed
some missing "note:"'s in the deprecated diagnostics that were showing
up in the unavailable diagnostics, etc.
This change also changes the wording of the core deprecation diagnostics.
Instead of saying "function has been explicitly marked deprecated"
we now saw "'X' has been been explicitly marked deprecated". It
turns out providing a bit more context is useful, and often we
got the actual term wrong or it was not very precise
(e.g., "function" instead of "destructor"). By just saying the name
of the thing that is deprecated/deleted/unavailable we define
this issue away. This diagnostic can likely be further wordsmithed
to be shorter.
llvm-svn: 197627
of objc_bridge_related attribute; eliminate
unnecessary diagnostics which is issued elsewhere,
fixit now produces a valid AST tree per convention.
This results in some simplification in handling of
this attribute as well. // rdar://15499111
llvm-svn: 197436
attribute in sema and issuing a variety of diagnostics lazily
for misuse of this attribute (and what to do) when converting
from CF types to ObjectiveC types (and vice versa).
// rdar://15499111
llvm-svn: 196629
Under ARC++, a reference to a const Objective-C pointer is implicitly
treated as __unsafe_unretained, and can be initialized with (e.g.) a
__strong lvalue. Make sure this behavior does not break template
argument deduction and (related) that partial ordering still prefers a
'T* const&' template over a 'T const&' template when this case kicks
in. Fixes <rdar://problem/14467941>.
llvm-svn: 194239
When performing an Objective-C message send to a value of class type,
perform a contextual conversion to an Objective-C pointer type. We've
had this for a long time, but it recently regressed. Fixes
<rdar://problem/15234703>.
llvm-svn: 194224
This patch essentially removes all the FIXMEs following calls to DeduceTemplateArguments() that want to keep track of deduction failure info.
llvm-svn: 186730
to provide proper overloading, and also prevents mangling conflicts with
template arguments of protocol-qualified type.
This is a non-backward-compatible mangling change, but per discussion with
John, the benefits outweigh this cost.
Fixes <rdar://problem/14074822>.
llvm-svn: 184250
is used for Objective-C++’s dictionary subscripting. This is done by filtering
out all placeholder types before check on lowering of the
common expression is done. // rdar://1374918.
Reviewed by John McCall.
llvm-svn: 182120
found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331
llvm-svn: 181847
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
llvm-svn: 181252
VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.
This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:
// expected-error@file:line {{diagnostic message}}
This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.
The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.
This closes out PR15613.
llvm-svn: 179677
* Give the right diagnostic for 'restrict' applied to a non-pointer, non-reference type.
* Don't reject 'restrict' applied indirectly to an Objective-C object pointer type (eg, through template instantiation).
llvm-svn: 178200
This was causing correctness issues for ARC and the static analyzer when a
function template has "consumed" Objective-C object parameters (i.e.
parameters that will be released by the function before returning).
The fix is threefold:
(1) Actually copy over the attributes from old ParmVarDecls to new ones.
(2) Have Sema::BuildFunctionType only work for building FunctionProtoTypes,
which it was doing anyway. This allows us to pass an ExtProtoInfo
instead of a plain ExtInfo and several flags.
(3) Drop param attributes as part of StripImplicitInstantiation, which is
used when an implicit instantiation is followed by an explicit one.
<rdar://problem/12685622>
llvm-svn: 176728
return type of a function by canonicalizing them away. They are
useless anyway, and conflict with our rules for template argument
deduction and __strong. Fixes <rdar://problem/12367446>.
llvm-svn: 172768
positions of Objective-C methods.
It is possible to recover a lot of type information about
Objective-C methods from the reflective metadata for their
implementations. This information is not rich when it
comes to struct types, however, and it is not possible to
produce a type in the debugger's round-tripped AST which
will really do anything useful during type-checking.
Therefore we allow __unknown_anytype in these positions,
which essentially disables type-checking for that argument.
We infer the parameter type to be the unqualified type of
the argument expression unless that expression is an
explicit cast, in which case it becomes the type-as-written
of that cast.
rdar://problem/12565338
llvm-svn: 167896
if the type of the value is a non-trivial class type. Fixes PR14318.
(There's a minor ObjC++ language change here: given that we can't save the
value, the type of the assignment expression is void in such cases.)
llvm-svn: 167884
source locations in places where it is necessary for diagnostics. By itself,
this causes assertions, so while I'm here, also fix property synthesis
for properties of C++ class type so we use so we properly set up a scope
and mark variable declarations.
<rdar://problem/12514189>.
llvm-svn: 166219
Also applies to -Wnonnull, -Wtype-safety, and -Wnon-pod-varargs.
All of these can be better checked at instantiation time.
This change does not actually affect regular CallExpr function calls,
since the checks there only happen after overload resolution.
However, it will affect Objective-C method calls.
<rdar://problem/12373934>
llvm-svn: 164984
in classes. Use it to flag those method implementations which don't
contain call to 'super' if they have 'super' class and it has the method
with this attribute set. This is wip. // rdar://6386358
llvm-svn: 163434
type is an unqualified objc pointer in arc. Treat it just
as being treated in c++98. This fixes a bogus vararg warning
with -std=c++11. //rdar://12229679
llvm-svn: 163236
statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in order to improve error recovery.
llvm-svn: 162464
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
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
of c-functions nested in namespace in method implementations
by turning off its delayed parsing until a proper solution is
figured out. pr13418
llvm-svn: 160552
[temp.deduct.call]p4 under Objective-C++ ARC, make sure to adjust the
qualifiers to introduce the implicit strong lifetime when
needed. Fixes <rdar://problem/11825671>.
llvm-svn: 160412
of out-of-line c++ method definition which happens
to be inside an objc class implementation
until I can figure out how to do it. This is to fix
a broken project.
llvm-svn: 159772
type traits that assignment to/construction of a lifetime-qualified
object under ARC is *not* trivial. Fixes <rdar://problem/11738725>.
llvm-svn: 159401
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
This could happen for cases like this:
- (NSArray *)getAllNames:(NSArray *)images {
NSMutableArray *results = [NSMutableArray array];
for (auto img in images) {
[results addObject:img.name];
}
return results;
}
Here the property access will fail because 'img' has type 'id', rather than,
say, NSImage.
This warning will not fire in templated code, since the 'id' could have
come from a template parameter.
llvm-svn: 158239
Previously we would reject it as illegal using a value of
enum type and on ObjC++ it was illegal to use an enumerator
as well.
rdar://11454917
llvm-svn: 156843
Fariborz Jahanian