Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
Now that we represent the Objective-C runtime names of classes and
protocols in a uniform way, stop peeking into the Clang AST nodes to
get this information for imported classes and protocols. This is
better layering and helps test that new code path.
Swift SVN r15632
immutable variables with a let prefix instead of a 'var' prefix. This allows
us to AST print this as 'let' instead of 'var', which isn't totally awesome,
but is better than misleading people with var.
func f() {
let x : Int = 42
}
Also, fix the SILPrinter to explode pattern binding decls, so that it doesn't
fall into the booby traps inherent in PatternBindingDecl printing.
Swift SVN r15393
This reverts commit r14488, since we're demoting 'type' back to a plain old identifier.
We could consider reallowing 'type' as a contextual keyword here, but from talking to Jordan he was OK with just reverting this functionality.
Swift SVN r14931
Previously this was spelled "import typealias", and that spelling will
continue to be allowed (since someone may specifically be importing a
typealias and want that to match), but now that 'type' is a keyword,
"import type" is the right way to spell the generic "import any type"
scoped import.
Swift SVN r14488
If an enum has no cases with payloads, make it implicitly Equatable and Hashable, and derive default implementations of '==' and 'hashValue'. Insert the derived '==' into module context wrapped in a new DerivedFileUnit kind, and arrange for it to be codegenned with the deriving EnumDecl by adding a 'DerivedOperatorDecls' array to NominalTypeDecls that gets visited at SILGen time.
Swift SVN r14471
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
separately from the get/set value. There is no exposed way in the
source language to use this, and this causes shorter term annoyance.
I chose to flatten the value and indices so the value comes first.
In principle, this allows us to completely eliminate our ObjC importer
thunks. I haven't removed them though, because they might be useful
for something else.
Swift SVN r14049
Previously, we would just parse vars and subscripts with no definitions,
then let getters and setters be referenced arbitrarily later. This was
problematic for a number of reasons, not least of which, the .sil file
might be invalid.
Instead, change sil to require that a protocol style definition indicate
whether a vardecl/subscript is computed or not, and whether it is both
get-able and set-able, e.g. like "var x : Int { get }". Change the
sil printer to print decls in this form, and change the SILParser to
make SILDeclRef::Func values instead of ::Getter/Setter values.
One thing that this exposed is that we weren't correctly serializing the
accessor state in modules, so accessors would get detatched from their
AbstractStorageDecls when deserialized (and in fact, their ASD never got
deserialized at all in some cases). Fix this in the serialization of
the accessors.
NFC, other than the SIL printer and parser.
Swift SVN r13884
- Alter parseSILType to take an optional GenericParamList out param to take the parsed GenericParamList, and use this to set the GenericParamList of parsed SILFunctions independent of their lowered type.
- Add a ContextGenericParams field to PrintOptions which, when set, provides a set of archetypes to print in place of the dependent types in an interface type.
- Use this to print the type of SILFunctions using their context generic params.
Swift SVN r13774
Introduce a new expression kind, OpenExistentialExpr, that "opens" up
an existential value into a value of a fresh archetype type that
represents the dynamic type of the existential. That value can be
referenced (via an OpaqueValueExpr) within the within the
subexpression of OpenExistentialExpr. For example, a call to a
DynamicSelf method on an existential looks something like this:
(open_existential_expr implicit type='P'
(opaque_value_expr implicit type='opened P' @ 0x7fd95207c290
unique)
(load_expr implicit type='P'
(declref_expr type='@lvalue P' decl=t.(file).func
decl.p@t.swift:5:37 specialized=no))
(erasure_expr implicit type='P'
(call_expr type='opened P'
(archetype_member_ref_expr type='() -> opened P'
decl=t.(file).P.f@t.swift:2:8 [with Self=opened P]
(opaque_value_expr implicit type='opened P' @
0x7fd95207c290 unique))
(tuple_expr type='()')))))
Note that we're using archetype_member_ref_expr rather than
existential_member_ref_expr, because the call is operating on the
opaque_value_expr of archetype type. The outer erasure turns the
archetype value back into an existential value.
The SILGen side of this is somewhat incomplete; we're using
project_existential[_ref] to open the existential, which is almost
correct: it gives us access to the value as an archetype, but IRGen
doesn't know to treat the archetype type as a fresh archetype whose
conformances come from the existential. Additionally, the output of
the opened type is not properly parsable. I'll fix this in follow-on
commits.
Finally, the type checker very narrowly introduces support for
OpenExistentialExpr as it pertains to DynamicSelf. However, this can
generalize to support all accesses into existentials, eliminating the
need for ExistentialMemberRef and ExistentialSubscript in the AST and
protocol_method in SIL, as well as enabling more advanced existential
features should we want them later.
Swift SVN r13740
