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
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
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
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
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
with FuncDecls. This allows us to eliminate special case code for handling
self in various parts of the compiler.
This also improves loc info (debug info and AST info) because 'self' now
has a location instead of being invalid.
I also took the opportunity to factor a bunch of places creating self decls
to use similar patterns and less copy and paste code.
Swift SVN r13196
Making DynamicSelf its own special type node makes it easier to opt-in
to the behavior we want rather than opting out of the behavior we
don't want. Some things already work better with this representation,
such as mangling and overriding; others are more broken, such as the
handling of DynamicSelf within generic classes and the lookup of the
DynamicSelf type.
Swift SVN r13141
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.
Swift SVN r13036
We add two records in sil_block to specify a witness table record and a method
entry record. Out of the four entry types, only "Method" is handled in this
commit.
Two records are also added to sil_index_block to search for a specific witness
table given a unique identifier. The interface lookupWitnessTable is not
implemented yet.
Right now, we serialize a witness table only when sil-serialize-all is on and
deserialize all witness tables in the module when sil-link-all is on.
rdar://15722175
Swift SVN r13000
This necessitated adding a new function to validate a serialized AST, so
that we can get the same information that used to be extracted from the
section header.
For now, we'll continue accepting the wrapped ASTs as well, since we
haven't changed the existing debug info generator.
Swift SVN r12922
We don't currently use this for anything, but if we have the module name
available and easy to access in the bitstream, we can drop the wrapper
around the serialized AST that's put into the binary itself for use by LLDB.
Swift SVN r12921
We don't currently use this for anything, but if we have the module name
available and easy to access in the bitstream, we can drop the wrapper
around the serialized AST that's put into the binary itself for use by LLDB.
Swift SVN r12919
Currently when compiling with debug info, the AST gets serialized into the
.o file for use by the debugger. However, when we switch to one .o file
per .swift file, this won't really make sense any more. Instead, we should
collect all the ASTs at the end of the build and merge them together, then
write /that/ into the final binary.
This commit handles writing a serialized AST with an LLDB wrapper around it,
so that we can take a merged AST, write it out in the wrapper, and splice it
into the final binary using ld's -sectcreate option.
In the long run, we probably won't need the LLDB wrapper, but for now I'm
trying to disturb as little as possible. (It looks like the layout is
broken on 32-bit platforms, though...there was a problem with 64-bit
relocations in the existing SwiftASTStreamerPass, but nothing ever tried to
/read/ the new layout in 32 bits. I'm holding off on dealing with this
right now.)
Part of <rdar://problem/15786017>
Swift SVN r12667
Lower types for SILDeclRefs from the interface types of their referents, dragging the old type along for the ride so we can still offer the context to clients that haven't been weaned off of it. Make SILFunctionType's interface types and generic signature independent arguments of its Derive the context types of SILFunctionType from the interface types, instead of the other way around. Do a bunch of annoying inseparable work in the AST and IRGen to accommodate the switchover.
Swift SVN r12536
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
This attribute states that all stored properties within the class must
provide initial values. This will allow us to move stored property
initialization into Objective-C's post-allocation initialization hook,
.cxx_construct.
Swift SVN r12228
Treat the interface types of SILFunctionTypes as the canonical representation in the verifier. Do a bunch of supporting and annoyingly irreducible work to enable this:
- Stop trying to uncurry generic parameter lists during type lowering and preserve the structure of AST GenericParamLists. This makes mapping dependent types into contexts easier.
- Properly walk generic parameter lists at all depths when grooming substitution vectors for use with substGenericArgs interfaces.
- Reseat the generic parameter lists created for protocol_method results so that we don't expect the outer Self archetype to be unbound; it's provided by the extra data of the result.
- Hack SILFunctionType serialization never to use a decl reference when serializing its generic param list. When this happens, we get incorrect archetypes. This is a gross hack, but when we're able to jump all the way to interface types, it can go away.
Putting these ducks in a row nicely un-XFAILs TextFormatting.swift.
Swift SVN r11989
For archetypes the conformance information is context dependent, the conformance
array is either empty or full of nulls and can be ignored. We uniform the two
cases by passing in an array of null pointers to writeConformances.
rdar://15693816
Swift SVN r11940
Attribute field is a fixed 2-bit field, but cast kind exceeds 4,
so using 2-bit attribute field for cast kind will cause overflow.
The fix is to add a record for the cast instruction with a 4-bit
kind field instead of a 2-bit attribute field.
Swift SVN r11938
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
