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
No validation is done yet on whether the user-specified access control makes
sense in context, but all ValueDecls should at least /have/ accessibility now.
/Still/ no tests yet. They will be much easier to write once we're actually
enforcing access control and/or printing access control.
Swift SVN r19143
These changes prevent a certain class of bogus errors, as well as several crashers. Unfortunately, though, they don't quite get us to the point where we can broadly use recursively defined protocol requirements, in the standard library. (To do so would require significant changes across the entire stack.)
Swift SVN r19019
In Swift, a type and a value (such as a function) will never have the same
name, but we import C tag types (structs, unions, and enums) into the same
namespace as values, which can lead to ambiguity. If the user has managed
to make clear which one they want in source code, though, we should preserve
that information during serialization.
<rdar://problem/16979415>
Swift SVN r18536
the current SIL module, unless the AST sees them first.
This turns out to be important when we deserialize generic
reabstraction thunks, which have shared linkage so get serialized
again in the current SIL module.
There are some fundamental inconsistencies in the way parameter type
decls are handled, but we need a quick workaround to unblock progress
on the stdlib.
Fixes
<rdar://problem/16807985> Building Foundation overlay crashes in stdlib deserialization in r17377
Swift SVN r18173
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
We used to just use FileContext at deserialization time. That causes
multiple NormalProtocolConformances with the same protocol and type,
but from different modules. And we will have issues at IRGen.
With this commit, we serialize the parent module and deserialize the parent
module, and we are not going to have multiple NormalProtocolConformances with
the same protocol and type.
rdar://16809311
Swift SVN r17675
This allows a loaded swiftmodule to refer to decls that come from a header
imported by the module itself. There's an unfortunate sharing of the
namespace here with any /other/ headers loaded by /other/ modules (including
the module currently being compiled), but that shouldn't be too much of an
issue in practice -- the declarations would need to be compatible anyway if
you were doing the same thing in Objective-C.
More of <rdar://problem/16702101>. This is possibly the end of the compiler
work, but I'd like to add more tests to make sure everything is working.
Swift SVN r17639
We were accidentally forcing all members of a class to be instantiated in two places:
- by trying to look up an existing destructor decl in the class, and
- by adding the implicit destructor to the class, because addMember needlessly called loadAllMembers.
Fix the former problem by adding a 'has destructor' bit to ClassDecl so we can track whether the implicit destructor needs to be added without querying its members. Fix the latter by making IterableDeclContext::addMember not call loadAllMembers, and making loadAllMembers not barf when it sees existing members in the context.
Together with Jordan and JoeP's changes, this makes many interpreter tests now compile 3-20x faster.
Swift SVN r17562
This basically just means "it's a CF class" for now,
but you could imagine applying this to all sorts of
class-like types from peer runtimes that we can't
support all possible language features for.
There are quite a few language features that require
fairly deep object-model integration to implement,
like subclassing and adding polymorphic methods.
Some of those features, like final classes, are useful
to generally support as attributes, but most of
them aren't. At least in the short term, it makes
sense to have a big hammer we can hit things with.
Swift SVN r17428
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
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
This will represent the return convention of imported __attribute__((objc_returns_inner_pointer)) methods. Leave it unimplemented for now until we can autorelease things sanely.
Swift SVN r16628
Use this node to capture the argument name and its source location in
the AST. We're only building these in one place at the moment; the
rest will be updated soon.
Swift SVN r16581
Before this fix, we can't deserialize any SILFunction with generic outer
parameters.
We do not have the decl associated with the generic parameter list at SIL level,
so instead of using a nullptr decl, we serialize the outer generic parameters
directly.
rdar://16630493
Swift SVN r16562
