When we deserialize a function that has a generic environment, set the
generic signature and a key to allow lazy creation of the generic
environment. Because most clients won't need the generic environment,
this lets us avoid creating generic environments.
Save two pointers of storage in IterableDeclContext (a base class of
nominal type and extension declarations) by storing the lazy member
loader + context data in an ASTContext side table. It also makes it
easier to add more lazy context information later on.
This method gets the GenericTypeDecl for a typealias, nominal type, or
extension thereof. While the result is typed as GenericTypeDecl, it's
not always generic, so rename it accordingly.
An audit of the callers illustrated that they should be using
different entrypoints anyway, so fix all of the callers and make this
function private.
DeclContext's nomenclature around "type contexts" is confusing,
because it essentially means "nominal type contexts", e.g.,
struct/class/enum/protocol and extensions thereof. This implies the
presence of a 'Self' type, the ability to have members, etc.
However, typealiases are also currently classified as "type
contexts", despite not having a reasonable 'Self' type, which breaks
in various places. Stop classifying typealiases as "type contexts".
First, ensure all ParamDecls that are synthesized from scratch are given
both a contextual type and an interface type.
For ParamDecls written in source, add a new recordParamType() method to
GenericTypeResolver. This calls setType() or setInterfaceType() as
appropriate.
Interestingly enough a handful of diagnostics in the test suite have
improved. I'm not sure why, but I'll take it.
The ParamDecl::createUnboundSelf() method is now only used in the parser,
and no longer sets the type of the self parameter to the unbound generic
type. This was wrong anyway, since the type was always being overwritten.
This allows us to remove DeclContext::getSelfTypeOfContext().
Also, ensure that FuncDecl::getBodyResultTypeLoc() always has an interface
type for synthesized declarations, eliminating a mapTypeOutOfContext()
call when computing the function interface type in configureInterfaceType().
Finally, clean up the logic for resolving the DynamicSelfType. We now
get the interface or contextual type of 'Self' via the resolver, instead
of always getting the contextual type and patching it up inside
configureInterfaceType().
There's a bit of a hack to deal with generic typealiases, but
overall this makes things more logical.
This is the last big refactoring before we can allow constrained
extensions to make generic parameters concrete. All that remains
is a small set of changes to SIL type lowering, and retooling
some diagnostics in Sema.
A GenericEnvironment stores the mapping between GenericTypeParamTypes
and context archetypes (or eventually, concrete types, once we allow
extensions to constrain a generic parameter to a concrete type).
The goals here are two-fold:
- Eliminate the GenericTypeParamDecl::getArchetype() method, and
always use mapTypeIntoContext() instead
- Replace SILFunction::ContextGenericParams with a GenericEnvironment
This patch adds the new data type as well as serializer and AST
verifier support. but nothing else uses it yet.
Note that GenericSignature::get() now asserts if there are no
generic parameters, instead of returning null. This requires a
few tweaks here and there.
Now that ConstraintSystem::openGeneric() is the only remaining
caller of this function, inline it in there and open-code the
logic.
Also, add a hack for opening nominal types contained inside
protocol types. This is invalid, but we should not crash, so
bind the type variable for the protocol 'Self' type to the
'Self' archetype, since it will not be equated with anything
otherwise.
There was a weird corner case with nested generic functions that
would fail in the SIL verifier with some nonsense about archetypes
out of context.
Fix this the "right" way, by re-working Sema function declaration
validation to assign generic signatures in a more principled way.
Previously, nested functions did not get an interface type unless
they themselves had generic parameters.
This was inconsistent with methods nested inside generic types,
which did get an interface type even if they themselves did not
have a generic parameter list.
There's some spill-over in SILGen from this change. Mostly it
makes things more consistent and fixes some corner cases.
If a function is public, and either @_transparent or @inline(__always),
we need to make its body available for inlining in other resilience
domains. The more general concept here is an 'inlineable' function;
once the precise behaviors we want are nailed down, the set of AST
attributes for exposing this will likely change.
At the SIL level, inlineable functions are marked with the [fragile]
attribute. The SIL serializer only serializes [fragile] functions
unless -sil-serialize-all is passed in.
This patch fixes two problems in this area by consolidating some
duplicated logic:
1) Property accesses in Sema did not check for @inline(__always)
functions, or functions nested inside inlineable functions.
This manifested as IRGen crashes if an inlineable function
accessed a property of a resilient type.
2) In SILGen, functions nested inside [fragile] functions were
properly [fragile], but @inline(__always) was not taken into
account. This manifested as SIL serializer crashes where a
[fragile] function could reference a non-public, non-[fragile]
function.
This change is part of the series for building the standard library
without -sil-serialize-all.
Fix some interface type/context type confusion in the AST synthesis from the previous patch, add a unique private mangling for behavior protocol conformances, and set up SILGen to emit the conformances when property declarations with behaviors are visited. Disable synthesis of the struct memberwise initializer if any instance properties use behaviors; codegen will need to be redesigned here.
Parse 'var [behavior] x: T', and when we see it, try to instantiate the property's
implementation in terms of the given behavior. To start out, behaviors are modeled
as protocols. If the protocol follows this pattern:
```
protocol behavior {
associatedtype Value
}
extension behavior {
var value: Value { ... }
}
```
then the property is instantiated by forming a conformance to `behavior` where
`Self` is bound to the enclosing type and `Value` is bound to the property's
declared type, and invoking the accessors of the `value` implementation:
```
struct Foo {
var [behavior] foo: Int
}
/* behaves like */
extension Foo: private behavior {
@implements(behavior.Value)
private typealias `[behavior].Value` = Int
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
If the protocol requires a `storage` member, and provides an `initStorage` method
to provide an initial value to the storage:
```
protocol storageBehavior {
associatedtype Value
var storage: Something<Value> { ... }
}
extension storageBehavior {
var value: Value { ... }
static func initStorage() -> Something<Value> { ... }
}
```
then a stored property of the appropriate type is instantiated to witness the
requirement, using `initStorage` to initialize:
```
struct Foo {
var [storageBehavior] foo: Int
}
/* behaves like */
extension Foo: private storageBehavior {
@implements(storageBehavior.Value)
private typealias `[storageBehavior].Value` = Int
@implements(storageBehavior.storage)
private var `[storageBehavior].storage`: Something<Int> = initStorage()
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
In either case, the `value` and `storage` properties should support any combination
of get-only/settable and mutating/nonmutating modifiers. The instantiated property
follows the settability and mutating-ness of the `value` implementation. The
protocol can also impose requirements on the `Self` and `Value` types.
Bells and whistles such as initializer expressions, accessors,
out-of-line initialization, etc. are not implemented. Additionally, behaviors
that instantiate storage are currently only supported on instance properties.
This also hasn't been tested past sema yet; SIL and IRGen will likely expose
additional issues.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
This is necessary for some other work I'm doing, which really wants
paramdecls to have reasonable declcontexts. It is also a small step
towards generic subscripts.
Now that generic signatures of types include generic parameters
introduced by outer generic functions, we need to know to skip
them when forming bound generic types or substitutions.
Add a function that computes the depth of the innermost generic
context that is not a generic type context.
Once nested generic parameter lists are properly chained, we need a
way of checking if we're inside a generic type context that's
distinct from just checking if we have a generic type signature
available.
This distinguishes between these two cases:
class A<T> {
// generic signature
func method() -> T { // <T> A<T> -> () -> T
}
}
func f<T>() {
class A {
// no generic signature
func method() -> T { // A -> () -> T
}
}
}
This is more complex than it could be if ExtensionDecl and NominalTypeDecl
had a common ancestor in the Decl hierarchy, however this is not possible
right now because TypeDecl inherits from ValueDecl.
Fixes <rdar://problem/20981254>.
Swift SVN r28941
Also allow cast<> from any Decl to DeclContext, not just ValueDecl.
An example of a Decl that is a DeclContext but not a ValueDecl is
ExtensionDecl.
The const_cast<> hack is horrid but its needed to deal with both const
and non-const operands in the patch that eventually uses this.
Note that this adds an explicit 'const auto' to the prior usage of
cast<DeclContext> in Mangling.cpp.
NFC
Progress on <rdar://problem/20981254>.
Swift SVN r28929
Resolve extensions when we need them, but don't bother when we
don't. Among other things, this lets us identify a protocol extension
before it's been fully validated. No behavior change for anything we
have written now.
Swift SVN r28891
This may not be the right solution. Even if it is, there are SourceKit tests
that need updating.
This reverts commit r28849 / rdar://problem/21007417.
Swift SVN r28852
Previously, we'd warn on this code:
enum Suit { case Spades, Hearts, Clubs, Diamonds }
extension Suit : Comparable {}
func <(...) {...}
because both Comparable and the synthesized conformance to Hashable imply
a conformance to Equatable. However, that's silly: Suit already has a
synthesized conformance to Equatable associated with the main 'enum'
declaration, not the extension. These compiler-provided conformances are
part of the language and something people rely on, so rank them higher than
conformances implied by conforming to a refined protocol.
rdar://problem/21007417
Swift SVN r28849
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Implement simplistic partial ordering rules for members of protocol
extensions. Specifically:
- A member of a concrete type is more specialized than a member of a
protocol extension
- A member of a protocol extension of P1 is more specialized than a
member of a protocol extension of P2 if P1 inherits from P2
This achieves most of what rdar://problem/20335936 covers, but does
not yet handle ordering between constrained protocol extensions.
Swift SVN r26723
Remove the semantic restrictions that prohibited extensions of
protocol types, and start making some systematic changes so that
protocol extensions start to make sense:
- Replace a lot of occurrences of isa<ProtocolDecl> and
dyn_cast<ProtocolDecl> on DeclContexts to use the new
DeclContext::isProtocolOrProtocolExtensionContext(), where we want
that behavior to apply equally to protocols and protocol extensions.
- Eliminate ProtocolDecl::getSelf() in favor of
DeclContext::getProtocolSelf(), which produces the appropriate
generic type parameter for the 'Self' of a protocol or protocol
extension. Update all of the callers of ProtocolDecl::getSelf()
appropriately.
- Update extension validation to appropriately form generic
parameter lists for protocol extensions.
- Methods in protocol extensions always use the witnesscc calling
convention.
At this point, we can type check and SILGen very basic definitions of
protocol extensions with methods that can call protocol requirements,
generic free functions, and other methods within the same protocol
extension.
Regresses four compiler crashers but improves three compiler
crashers... we'll call that "progress"; the four regressions all hit
the same assertion in the constraint system that will likely be
addressed as protocol extensions starts working.
Swift SVN r26579
When code completing a literal expr, it is likely that code completion engine only collects the expr
that is not fully type checked. Therefore, no members of the literal can be suggested. To address this,
we try to climb up expr hierarchy in AST to find an expr with a nominal type, and use the nominal type
to finish code completion.
rdar://20059173
Swift SVN r26116
(Note that this registry isn't fully enabled yet; it's built so that
we can test it, but has not yet taken over the primary task of
managing conformances from the existing system).
The conformance registry tracks all of the protocols to which a
particular nominal type conforms, including those for which
conformance was explicitly specified, implied by other explicit
conformances, inherited from a superclass, or synthesized by the
implementation.
The conformance registry is a lazily-built data structure designed for
multi-file support (which has been a problematic area for protocol
conformances). It allows one to query for the conformances of a type
to a particular protocol, enumerate all protocols to which a type
conforms, and enumerate all of the conformances that are associated
with a particular declaration context (important to eliminate
duplicated witness tables).
The conformance registry diagnoses conflicts and ambiguities among
different conformances of the same type to the same protocol. There
are three common cases where we'll see a diagnostic:
1) Redundant explicit conformance of a type to a protocol:
protocol P { }
struct X : P { }
extension X : P { } // error: redundant explicit conformance
2) Explicit conformance to a protocol that collides with an inherited
conformance:
protocol P { }
class Super : P { }
class Sub : Super, P { } // error: redundant explicit conformance
3) Ambiguous placement of an implied conformance:
protocol P1 { }
protocol P2 : P1 { }
protocol P3 : P1 { }
struct Y { }
extension Y : P2 { }
extension Y : P3 { } // error: ambiguous implied conformance to 'P1'
This happens when two different explicit conformances (here, P2 and
P3) placed on different declarations (e.g., two extensions, or the
original definition and other extension) both imply the same
conformance (P1), and neither of the explicit conformances imply
each other. We require the user to explicitly specify the ambiguous
conformance to break the ambiguity and associate the witness table
with a specific context.
Swift SVN r26067
