@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
I can't actually reproduce the buildbot failure that happened last night, so
hopefully it will (a) happen again, so I can investigate, or (b) not happen
again.
Swift SVN r22230
FixNum.h and BCRecordLayout.h will move down into LLVM, APINotes
will move into Clang. Get the namespaces right before we start to move
files around.
Swift SVN r22218
conformances (22195 to 22199).
It broke tests:
Failing Tests (4):
Swift :: Interpreter/SDK/Foundation_NSString.swift
Swift :: SIL/Serialization/deserialize_appkit.sil
Swift :: SIL/Serialization/deserialize_foundation.sil
Swift :: stdlib/NSStringAPI.swift
Swift SVN r22214
Doug had changed the comment but not the implementation -- we were still
serializing the containing module rather than the declaring nominal or
extension.
Found by enabling verification on deserialized decls (to come soon).
Swift SVN r22198
This reduces the chances of conflict among inner class names. It's too easy
for a class to be implicitly marked @objc in Swift.
To make this work, correctly preserve the implicitness of @objc through
serialization. (We were probably intending to do this all along, since we
were serializing the flag but not doing anything with it at the other end.)
Swift SVN r21678
This should not have any observable effect, but it means the compiler won't
waste time validating the attributes of deserialized declarations.
Swift SVN r21499
We now have this information during parsing and throw it away during deserialization. This half-baked state works because all non-generic-extension clients only care about the module context.
Swift SVN r20833
Previously, we only retained the module in which a normal protocol
conformance occurred, which meant we either had to go searching for
the appropriate extension (yuck) or do without that information. This
is part of the separating-extension-archetypes work.
Swift SVN r20793
The eventual goal for extensions of generic types is to require them
to specify their generic parameters, e.g.,
extension Array<T> { ... }
rather than today's
extension Array { ... }
Start parsing (optional) generic parameters here, and update the
representation of ExtensionDecl to accomodate this new grammar
production. Aside from the parser changes, there's no intended
functionality change here.
Swift SVN r20682
This adds generic parameters and generic signatures to extension
declarations. The actual generic parameters just mirror what is
available on the extended type; however, it is filled in via extension
validation, which is handled lazily.
This is a NFC step toward decoupling the archetypes of extensions from
the archetypes of the extended types <rdar://problem/16974298>.
Swift SVN r20675
Previously, we were just storing setter accessibility via the accessibility
level on the setter function. However, some Stored properties never actually
have a setter synthesized, which led to the compiler dropping the setter
accessibility at serialization time. Rather than try to hack up something
clever, just store the setter accessibility explicitly in every
AbstractStorageDecl. (We still only serialize it for VarDecls, because
settable SubscriptDecls always have setter functions.)
<rdar://problem/17816530>
Swift SVN r20598
to emit fixit's when we rename something, e.g.:
t.swift:6:9: error: 'float' has been renamed to Float
var y : float
^~~~~
Float
Adopt this in the stdlib.
Swift SVN r20549
it indirectly through another pointer from Decl, just embed DeclAttributes
directly into Decl and get rid of the "getMutableAttrs" nonsense.
Swift SVN r20216
To answer "did the user specify this, or is it implicit", stick a couple
of is-implicit bits in InfixOperatorDecl, and thread them through
serializaton/deserialization.
Swift SVN r20067
attribute. As part of this, introduce a new "NotSerialized" flag in Attr.def.
This eliminates a bunch of special case code in the parser and elsewhere for handling
this modifier.
Swift SVN r19997
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
We still have type checker support for user-defined conversions,
because the importer still synthesizes __conversion functions for CF
<-> NS classes.
Swift SVN r19813
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
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
When we import factory methods as initializers, we can end up with two initializers that have the same name and type but different kinds. This will differentiate them. Tripped over this while investigating <rdar://problem/17411843>
Swift SVN r19440
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
