getAll deserializes all SIL (except for globals). This enables us to iterate
over the SILModules once instead of once for first SILFunctions, then VTables,
then WitnessTables which is just inefficient.
Swift SVN r14176
This enables us to lookup a function from a key by avoiding the need to create
an identifier inside the OnDiskHashTable structure. Doing so would require an
ASTContext, something that is not available therein.
As a side effect this also makes OnDiskHashTable more efficient by just using a
StringRef reference instead of creating a uniqued identifier in the AST for
every deserialized node in the table.
Swift SVN r14169
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from
the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're
serializing a complete definition. This fixes issues with us getting the
wrong archetypes forward-declared from references in other modules.
In this version of the patch, we adjust the deserialization point for the
generic param list to correctly come before we check if the SILFunction block
is empty, and we add a kludge to keep the JIT from crapping itself when it sees
the same transparent definition in multiple REPL lines' modules
<rdar://problem/16094902>.
The previous commit solves a problem this exposed at r14050 in inout deshadowing
that caused memory corruption when transparent functions were imported. This
should now be safe to commit.
Swift SVN r14109
Introduce the SIL instructions thick_to_objc_metatype and
objc_to_thick_metatype to convert between the 'thick' and
'Objective-C' representations of a metatype. Most of this code is
trivial support code for these conversions: printing, parsing,
(de-)serialization, etc., for which testing will come online in
subsequent patches or is incidental in other tests.
Lower Objective-C metatype values down to objc_class* at the IR level
and implement IRGen support for these SIL instructions. SIL-only test
case at the moment because SILGen never creates these instructions.
Swift SVN r14087
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
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're serializing a complete definition. This fixes issues with us getting the wrong archetypes forward-declared from references in other modules.
In this version of the patch, we adjust the deserialization point for the generic param list to correctly come before we check if the SILFunction block is empty, and we add a kludge to keep the JIT from crapping itself when it sees the same transparent definition in multiple REPL lines' modules <rdar://problem/16094902>.
Swift SVN r14030
- Parameterize maybeReadGenericParams' BitstreamCursor so that we can read from the correct cursor when trying to read the generic params of a SILFunction.
- Only serialize the context generic params for SILFunctions for which we're serializing a complete definition. This fixes issues with us getting the wrong archetypes forward-declared from references in other modules.
This gets me a clean build when applied against r13984.
Swift SVN r14005
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
The name Stream didn't seem to be working out as intended; we kept
gravitating back to calling it Generator, which is precedented in other
languages. Also, Stream seems to beg for qualification as Input or
Output. I think we'd like to reserve Stream for things that are more
bulk-character-API-ish.
Swift SVN r13893
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
Riding off of project_existential[_ref] was convenient, but the
resuls are used quite differently. Note that open_existential[_ref]
still don't print/parse reasonably yet.
Swift SVN r13878
From now on, /any/ changes to SIL or AST serialization must increment
VERSION_MINOR in ModuleFormat.h.
The original intent of VERSION_MAJOR/VERSION_MINOR was that VERSION_MAJOR
would only increment when backwards-incompatible changes are introduced,
and VERSION_MINOR merely indicates whether to expect additional information.
However, the module infrastructure currently isn't forgiving enough to accept
even backwards-compatible changes to the record schemas, and the SIL
serialization design might not be compatible with that at all.
So for now, treat any version number 0.x as incompatible with any other 0.y.
We can bump to 1 when we hit stability.
<rdar://problem/15494343>
Swift SVN r13841
We kinda need those. Limit the hack to pad it out with nulls to only apply in the case when the conformance list is empty but the original archetype requires conformances, which only occurs for archetypes or existentials.
At long last, we can build at -O0 again, again! Reapplying now that Jordan fixed some fallout this had on his objc printer tests. Thanks Jordan!
Swift SVN r13840
GenericSignatures with no params or requirements are a bug, so verify that they don't happen by making GenericSignature::get return null and GenericFunctionType assert that it has a nonnull signature. Hack Sema not to try to produce nongeneric GenericFunctionTypes when a function in a local type in a generic function context is type-checked; there's a deeper modeling issue that needs to be fixed here, but that's beyond the scope of 1.0. Now that GenericSignature always has at least one subtype, its factories no longer need an independent ASTContext argument.
Swift SVN r13837
We kinda need those. Limit the hack to pad it out with nulls to only apply in the case when the conformance list is empty but the original archetype requires conformances, which only occurs for archetypes or existentials.
At long last, we can build at -O0 again!
Swift SVN r13815
Change GenericFunctionType to reference a GenericSignature instead of containing its generic parameters and requirements in-line, and clean up some interface type APIs that awkwardly returned ArrayRef pairs to instead return GenericSignatures instead.
Swift SVN r13807
This is mostly useful for the standard library, whose name is going to
change to "Swift" soon. (See <rdar://problem/15972383>.) But it's good DRY.
Swift SVN r13758
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
There are some straggling references to the context generic param list, but nothing uses the non-interface param or result types anymore!
Swift SVN r13725
SubscriptDecl is created, then the accessors are installed on it.
This allows us to create the subscript decl before the accessors
have been parsed, allowing us to build the subscript even in invalid
cases (better for later error recovery).
More importantly, this allows us to add it to Decls before calling
parseGetSet, so we can now make parseGetSet add accessors to Decls
without breaking source order (something that deeply upsets the IDE
features).
With all this untangled, we can now remove the 'addAccessorsInOrder'
hack where we parsed the accessors and then later tried to figure out
which order they came for the purpose of linking up the AST: accessors
now work just like everything else.
Swift SVN r13708
now that they are implicitly updated. This exposes two things:
1) we're unncessarily serializing selfdecls in ctors and dtors.
2) The index pattern of a SubscriptDecl has no sensible DeclContext that
owns variables in it.
I'll deal with the first tomorrow, I'm not sure what to do with
the second one.
Swift SVN r13703
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
Edge SILFunction one step closer to independence from SILFunctionType context by taking the generic param list as a separate constructor parameter, and serializing those params alongside the function record. For now we still pass in the context params from the SILFunctionType in most cases, because the logic for finding the generic params tends to be entangled in type lowering, but this pushes the problem up a step.
Thanks Jordan for helping work out the serialization changes needed.
Compared to r13036, this version of the patch includes the decls_block RecordKind enumerators for the GENERIC_PARAM_LIST layouts in the sil_block RecordKind enumerator, as Jordan had suggested before. r13036 caused buildbot failures when building for iOS, but I am unable to reproduce those failures locally now.
Swift SVN r13485
This re-applies r13401, reverted in r13404. This wasn't actually causing
problems, but got pulled along with r13400 (reverted in r13405).
Swift SVN r13452
