This attribute is supported by GCC. More generally it should
probably be a type attribute, but this behavior matches 'nonnull'.
This patch does not include warning logic for checking if a null
value is returned from a function annotated with this attribute.
That will come in subsequent patches.
llvm-svn: 199626
This allows the following syntax:
void baz(__attribute__((nonnull)) const char *str);
instead of:
void baz(const char *str) __attribute__((nonnull(1)));
This also extends to Objective-C methods.
The checking logic in Sema is not as clean as I would like. Effectively
now we need to check both the FunctionDecl/ObjCMethodDecl and the parameters,
so the point of truth is spread in two places, but the logic isn't that
cumbersome.
Implements <rdar://problem/14691443>.
llvm-svn: 199467
Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it.
llvm-svn: 199378
consumable objects. These are useful for implementing error codes that
must be checked. Patch also includes some significant refactoring, which was
necesary to implement the new behavior.
llvm-svn: 199169
Since this warning was generalized, it was also given a sensible warning group flag and the corresponding test was updated to reflect this.
llvm-svn: 198053
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
That's a mouthful, and not necessarily the final name. This also
reflects a semantic change where this attribute is now on the
protocol itself instead of a class. This attribute will require
that a protocol, when adopted by a class, is explicitly implemented
by the class itself (instead of walking the super class chain).
Note that this attribute is not "done". This should be considered
a WIP.
llvm-svn: 196955
which specifies couple of (optional) method selectors
for bridging a CFobject to or from an ObjectiveC
object. This is wip. // rdsr://15499111
llvm-svn: 196408
designated initializers of an interface.
If the interface declaration does not have methods marked as designated
initializers then the interface inherits the designated initializers of
its super class.
llvm-svn: 196315
I have disabled some attribute subject lines on purpose in Attr.td;
this part is a WIP with the goal being to restore those subjects
incrementally. By commenting them out, it leaves the original behavior
the same as before for those attributes and so those are not
functionality changes.
llvm-svn: 195841
look at the attribute spelling instead. The 'ownership_*' attributes should
probably be split into separate *Attr classes, but that's more than I wanted to
do here.
llvm-svn: 195805
This is still an experimental attribute, but I wanted it in tree
for review. It may still get yanked.
This attribute can only be applied to a class @interface, not
a class extension or category. It does not change the type
system rules for Objective-C, but rather the implementation checking
for Objective-C classes that explicitly conform to a protocol.
During protocol conformance checking, clang recursively searches
up the class hierarchy for the set of methods that compose
a protocol. This attribute will cause the compiler to not consider
the methods contributed by a super class, its categories, and those
from its ancestor classes. Thus this attribute is used to force
subclasses to redeclare (and hopefully re-implement) methods if
they decide to explicitly conform to a protocol where some of those
methods may be provided by a super class.
This attribute intentionally leaves out properties, which are associated
with state. This attribute only considers methods (at least right now)
that are non-property accessors. These represent methods that "do something"
as dictated by the protocol. This may be further refined, and this
should be considered a WIP until documentation gets written or this
gets removed.
llvm-svn: 195533
whose semantic is currently identical to objc_bridge,
but their differences may manifest down the road with
further enhancements. // rdar://15498044
llvm-svn: 195376
After implementing this patch, a few concerns about the language
feature itself emerged in my head that I had previously not considered.
I want to resolve those design concerns first before having
a half-designed language feature in the tree.
llvm-svn: 195328
The idea is to allow a class to stipulate that its methods (and those
of its parents) cannot be used for protocol conformance in a subclass.
A subclass is then explicitly required to re-implement those methods
of they are present in the class marked with this attribute.
Currently the attribute can only be applied to an @interface, and
not a category or class extension. This is by design. Unlike
protocol conformance, where a category can add explicit conformance
of a protocol to class, this anti-conformance really needs to be
observed uniformly by all clients of the class. That's because
the absence of the attribute implies more permissive checking of
protocol conformance.
This unfortunately required changing method lookup in ObjCInterfaceDecl
to take an optional protocol parameter. This should not slow down
method lookup in most cases, and is just used for protocol conformance.
llvm-svn: 195323
into a separate "parse an attribute that takes a type argument" codepath. This
results in both codepaths being a lot cleaner and simpler, and fixes some bugs
where the type argument handling bled into the expression argument handling and
caused us to both accept invalid and reject valid attribute arguments.
llvm-svn: 193731
This reverts commit r193161.
It broke
void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));
Looks like we have to fix pr17639 first :-(
llvm-svn: 193162
names. For example, with this patch we now reject
void f1(void) __attribute__((alias("g1")));
This patch is implemented in CodeGen. It is quiet a bit simpler and more
compatible with gcc than implementing it in Sema. The downside is that the
errors only fire during -emit-llvm.
llvm-svn: 193161
ResolveSingleFunctionTemplateSpecialization() returns 0 and doesn't emit diags
unless the expression has template-ids, so we must null check the result.
Also add a better diag noting which overloads are causing the problem.
Reviewed by Aaron Ballman.
llvm-svn: 193055
to be treated as return values, and marked with the "returned_typestate"
attribute. Patch by chris.wailes@gmail.com; reviewed by delesley@google.com.
llvm-svn: 192932
Aaron Ballman