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
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
Via preprocessor goop, Serialization.cpp generates a set of static
functions that can be used to verify if a set of attributes
can be serialized for a particular declaration.
This design forces the author of the attribute to specify up front
whether or not an attribute is supported on a given declaration
kind. We can possibly hoist this into semantic analysis as well.
These N separate functions do conceptually replace a simple
variadic template implementation. I'm fine with alternatives,
but the goal was to provide a way for the author of new
attributes to describe the requirements in one place: Attr.def.
Swift SVN r15470
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
"@mutating func f()". I'm keeping the @mutating version around
so we can determine what to do with @!mutating.
Also, improve the QoI of mutating related diagnostics.
Swift SVN r13480
This attribute states that all stored properties within the class must
provide initial values. This will allow us to move stored property
initialization into Objective-C's post-allocation initialization hook,
.cxx_construct.
Swift SVN r12228
AttributeId: Any occurence of '@<attribute-name>' anywhere.
AttributeBuiltin: A "resolved/active" attribute. Mis-applied attributes will be AttributeId.
This provides more options for coloring attributes in a way that one can easily spot
attributes that are not applied correctly.
Swift SVN r12194
- Switch @mutable to be a tri-state attribute that is invertable with @!mutable.
- Move the semantic form of 'mutable' to being a bit on FuncDecl instead of
something in DeclAttrs. The former is a binary bit, the later is a tristate
which differentiates between "not present", "present and set" "present and inverted".
- Diagnose some invalid uses of @mutable, e.g. on class methods.
- Make setters default to mutable, and allow them to be switched with @!mutable.
Swift SVN r11439
1) on decls, they say the decl is weak/unowned.
2) in sil mode, on types, they indicate that the type has weak/unowned storage.
Since these are different things, split the SIL type attributes out to new
attributes (sil_weak/sil_unowned) to crystalize the relationship.
Swift SVN r9270
specific to types. While we're at it, improve the diagnostic for when a decl-specific
attribute is applied to a type, or a type-specific attribute is applied to a decl.
Swift SVN r9268
of having a ton of ad-hoc bools in it. This allows us to consolidate a ton of
boilerplate, eliminating 250 lines of code:
17 files changed, 435 insertions(+), 662 deletions(-)
2) This eliminates the special case for weak and unowned attributes, which previously
didn't show up in Attr.def.
3) While we're at it, keep track of proper source locations for each attribute, and
use these to emit diagnostics pointing at the attribute in question instead of at
a funcdecl or the @ sign.
4) Fix axle attributes, which had vertex and fragment swapped.
Swift SVN r9263
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
