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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167896 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167884 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166219 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164984 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163434 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163236 91177308-0d34-0410-b5e6-96231b3b80d8
method parameter types which are reference to an objective-C
pointer to object with no explicit ownership. // rdar://10907090
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162959 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162464 91177308-0d34-0410-b5e6-96231b3b80d8
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'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160998 91177308-0d34-0410-b5e6-96231b3b80d8
are cast to retainable types, only suggest CFBridgingRelease/
CFBridgingRetain and not the __bridge casts.
// rdar://11923822
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160900 91177308-0d34-0410-b5e6-96231b3b80d8
retainable types in arc, only suggest CFBridgingRelease/
CFBridgingRetain and not the confusing __bridge casts.
// rdar://11923822
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160839 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160615 91177308-0d34-0410-b5e6-96231b3b80d8
of c-functions nested in namespace in method implementations
by turning off its delayed parsing until a proper solution is
figured out. pr13418
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160552 91177308-0d34-0410-b5e6-96231b3b80d8
[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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160412 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159772 91177308-0d34-0410-b5e6-96231b3b80d8
type traits that assignment to/construction of a lifetime-qualified
object under ARC is *not* trivial. Fixes <rdar://problem/11738725>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159401 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158793 91177308-0d34-0410-b5e6-96231b3b80d8
There was already a test that it did not fire in type-dependent contexts.
This was already behaving correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158530 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158239 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156843 91177308-0d34-0410-b5e6-96231b3b80d8
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154187 91177308-0d34-0410-b5e6-96231b3b80d8
Eli Friedman
NAKAMURA Takumi
John McCall
Douglas Gregor
Andy Gibbs
Jordan Rose
Fariborz Jahanian
Richard Smith
Argyrios Kyrtzidis
Patrick Beard