- 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
wire it up, do basic semantic analysis and code gen a simple case of it. There is
more type checking work to come, so it isn't complete yet.
This is the first step to:
<rdar://problem/15864836> Need a @NSCopying attribute for Cocoa types that aren't manually bridged
Swift SVN r16345
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
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
The parsing here for @availability isn't real yet; but it provides
scaffolding. Intended grammar:
@availability(*, unavailable, message="...")
@availability(*, unavailable)
@availability(ios, unavailable)
and so on.
Much of this doesn't work yet in a general way, but I wanted something
basic to work with to start with to wire up the functionality
for @availability end-to-end (at least for 'unavailable').
As part of this, extend DECL_ATTR to include whether or not an
attribute supports multiple declarations, and use this for
@availability.
Also hardwire darwin platforms, which we will need to have this
list come from somewhere. The checking could be done at parsing
or elsewhere.
Swift SVN r15491
This representation is inspired by Clang's internal representation.
The current attribute representation, which is basically a union
of "stuff" in DeclAttributes, is not amendable to richer
attributes, such as @availability, that need to be implemented.
In Clang, attributes are modeled with actual objects that
encode both semantic and syntactic information (e.g., source ranges)
that facilitate richer checking, better diagnostics, and better tools.
This change is foundational for implementing @availability, but
also is a better long-term representation. As a migratory path,
it creates some duplications, with AttrKind and DeclAttrKind, the
two which should eventually become the same thing.
As part of this patch, there is some additional parser recovery
(for the new attribute representation) for duplicate attributes.
The parser now parses the entire duplicate attribute, which could
be quite complex, and then issues a diagnostic that the attribute
is a duplicate (and discarding it). This delayed diagnostic
also allows us to present ranges for the duplicate attribute, which
provides a better user experience.
Swift SVN r15365
The 'override' attribute indicates that the given declaration, which
may be a method, property, or subscript, overrides a declaration in
its superclass. Per today's discussion, the 'override' attribute must
be present if and only if the corresponding declaration overrides a
declaration in its superclass.
This implements most of <rdar://problem/14798539>. There's still more
work to do to on property and subscript overrides.
Swift SVN r14388
We can attach comments to declarations. Right now we only support comments
that precede the declarations (trailing comments will be supported later).
The implementation approach is different from one we have in Clang. In Swift
the Lexer attaches the comments to the next token, and parser checks if
comments are present on the first token of the declaration. This is much
cleaner, and faster than Clang's approach (where we perform a binary search on
source locations and do ad-hoc fixups afterwards).
The comment <-> decl correspondence is modeled as "virtual" attributes that can
not be spelled in the source. These attributes are not serialized at the
moment -- this will be implemented later.
Swift SVN r14031
...rather than a raw pointer that points to a buffer with space for N
elements. Just because we *can* get N from context doesn't mean it's
convenient/safe.
No functionality change.
Swift SVN r11488
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
and remove DeclContext base class from FuncDecl, ConstructorDecl and
DestructorDecl
This decreases the number of DeclContexts to 7 and allows us to apply
alignas(8) to DeclContext.
Swift SVN r8186
