attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
Parse 'dynamic' as a contextual keyword, and check that it's applied only to ObjC-compatible members of classes. We don't handle inheritance of the attribute yet.
Swift SVN r19781
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
This is a WIP. This patch includes:
- Adds version tuple information for 'introduced', 'deprecated',
and 'obsoleted' to the 'availability' attribute.
- Add Clang importer support to import __attribute__((availability))
version tuples into Swift as pieces of the 'availability'
attribute.
- Add serialization support for the 'availability' attribute with
this extra information. This is not tested other than the
tests currently passing. This is not expected to be
really exercised (with interesting versions) until
parsing support is added for the version tuples. However,
existing @availability attributes in the test suite are being
serialized, which should just include "empty" version information.
What's not in this patch:
- Parsing support in Swift for 'deprecated', 'introduced', or
'obsoleted'. All of this information is currently being pulled
in from the Clang Importer.
- Warning support for using deprecated declarations based on the
availability information and the minimum deployment target.
- Some harmony reconciling the 'IsUnavailable' field in
AvailabilityAttr, which attempts to eagerly compute if something
is unavailable so we don't have to replicate the checking logic
elsewhere. The idea is that when we either import availability
information or lazily deserialize it we can compute whether or
not something is conditionally unavailable or deprecated right
there, and not have to have all clients within the frontend
of the availability information need to pass the minimum
deployment target. Right now 'IsUnavailable' is also used
to encode if the attribute represents unconditional unavailability,
e.g. @availability(*, unavailable).
This patch, however, should contain enough information to start
looking at implementing weak linking support.
NOTE: the serialization of the attribute is a bit ugly. I wasn't
certain if Jordan's serialization meta-programming supported
serializing values that decomposed into multiple values in a record,
so this ugly macro-based implementation is in place which compacts
all the version tuple information for an availability attribute
into a single record.
Swift SVN r19487
...unless the type has less accessibility than the protocol, in which case
they must be as accessible as the type.
This restriction applies even with access control checking disabled, but
shouldn't affect any decls not already marked with access control modifiers.
Swift SVN r19382
The @semantics attribute allows the stdlib to mark some functions as
having a specific semantics. The optimizer can use this information
to optimize the code.
Swift SVN r19328
This does no validation of the access control modifiers.
As part of this commit, note that "virtual" attributes may actually be
written in the source under another spelling. Update a few other parts of
the source to account for that.
Swift SVN r19140
This hardcodes the list of platforms into unique identifiers, which
has tradeoffs to using strings. The reality is that various
logic in the compiler needs to be present to identify a given
platform, so hardcoding this list for now is ok. We can evaluate
in the future.
This change is motivated by some needed cleanup, supporting
App Extensions @availability, and unifying build configurations
with the platform names for @availability.
As part of this change, it introduces some slightly better
parser recovery for bad @availability attributes.
Moreover, the 'macosx' platform is renamed to 'osx'. We will need
to handle this mapping in the Clang Importer, but this is the
right thing to do.
Swift SVN r17767
- Change the parser to unconditionally reject @mutating and @!mutating with a fixit and
specific diagnostic to rewrite them into the [non]mutating keyword.
- Update tests.
This resolves <rdar://problem/16735619> introduce nonmutating CS keyword and remove the attribute form of mutating all together
Swift SVN r16892
This was part of the original weak design that
there was never any particular reason to rush the
implementation for. It's convenient to do this now
so that we can use it to implement Unmanaged<T> for
importing CF types.
Swift SVN r16693
We have to work with selectors quite often, so provide an efficient
representation for them. Switch ObjCAttr over to this representation,
which has the nice property that it efficiently represents implicit
@objc attributes with names and allows us to overwrite the Objective-C
name without losing all source information. Addresses
<rdar://problem/16478678>, and sets us up for dealing with selectors
better.
Swift SVN r16327
... and fix a few other bugs:
* always set the inherited protocols on the ProtocolDecl in the type checker,
so that we can remove a hack in ProtocolDecl::requiresClassSlow();
* diagnose DeclAttributes that are inverted when this is not allowed.
Swift SVN r15992
To generalize our serialization logic for more attributes, serialize
each DeclAttribute object in a separate bitcode record.
For simple declaration attributes (no arguments), all of this
serialization logic can be fully automatically generated, and is
done so in this patch. This currently includes @final, but will
expand over time.
To illustrate the plumbing end-to-end, move the serialization logic
for asmnmame over to the new mechanism.
Swift SVN r15933
The new "final" attribute didn't have a DeclAttribute subclass. While
that sounds like a nice simplification, it makes visitors awkward to
use.
Swift SVN r15899
This is missing almost all semantic analysis and is missing various
optimization opportunities (e.g. final methods that are not overrides
don't need vtable entries), but this is enough to devirtualize class
stuff, which is important for our performance efforts. I'll add this
to release notes when it is more fully fleshed out.
Swift SVN r15885
With this in place, remove the hacks that peeked at the imported Clang
node to determine the selector for a method. We're all
attribute-driven now. Part of <rdar://problem/16019773>.
Swift SVN r15663
Protocols can declare methods as being unavailable, as they do
in NSObjectProtocol (e.g., 'retain'). We both need to flag these
uses, but understand this for protocol conformance. For protocol
conformance, treat unavailable methods as if they were marked
optional. The compiler will not allow you to use these methods
anyway.
This finishes up support for:
<rdar://problem/16331335> Ban ObjC ARC entry points
Swift SVN r15644
This is a direct translation which happens when a Clang declaration
gets translated to a Swift declaration. This changed, coupled
with the current @availability checking (which is still limited)
now prohibits cases such as using 'NSDeallocateObject()' or
'- (BOOL) allowsWeakReference' from Swift.
Interestingly, it doesn't catch uses of -retain/-release yet, because
those methods are marked unavailable in the NSObject *protocol*.
While the attributes are being mapped over, the @availability
checking needs to be enhanced to replicate more of what Clang does
for this case.
Swift SVN r15643
The @objc attribute can now be provided with a name (in parentheses),
which names the corresponding entity in Objective-C. The name will
either be a selector (for anything that maps down to an Objective-C
method) or a single identifier (for classes and protocols).
The extra information is not used for anything yet.
Swift SVN r15626
For example:
@class_protocol, @objc
is now just:
@class_protocol @objc
Once we removed attribute grouping in brackets this comma separation
became vestigial. Doug and I discussed this and thought this
was a good simplification in the grammar.
This change still remains to be done for type attributes.
Swift SVN r15540
