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
Instead for vardecls, we use the index of the field in the structdecl itself as
a stable ordering of vardecls.
I validated that the indeterminism was gone by running the failing test 1000
times in a row. Doug and I were hitting the indeterminism with well less than
100 iterations before, so I feel the number of iterations is sufficient.
Swift SVN r13859
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
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
Most of the complexity here is teaching SILGen how to handle closed-over direct
accesses to observing properties, since all of the getter/setter/willSet/didSet
members of the property are actually full closures when in a function body.
We generate correct but really terrible code here, since the setter captures the
willset/didset members themselves. I'm not worrying about the performance of
this construct though, functionality is what matters.
Swift SVN r13778
- 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
We still glue the generic params of the requirement to the generic params of the conformance, but now we do it without relying on TypeLowering.
Swift SVN r13771
Pass the context generic params for a reabstraction thunk down to getOrCreateReabstractionThunk from the enclosing function, where it can either use them to define a new thunk or ignore them if it has an equivalent thunk already. Tweak the mangling of reabstraction thunks to use the generic signature with decontextualized "from" and "to" types instead of the generic param list.
Swift SVN r13763
Instead of relying on type lowering to produce a contextualized SILFunctionType from which we can borrow context generic params, add a getConstantContextGenericParams that grabs the generic param list for a SILDeclRef independent of the function type, severing another dependency on SILFunctionType's context params.
Swift SVN r13743
We were using SILFunctionType::getGenericParams to apply the outer generic parameters to the SILConstant for an inner context, which is on life support. This is the correct way to get that info going forward.
Swift SVN r13742
These uses just shuttle a param list from one place to another and can be trivially dropped when we're ready to kill getGenericParams altogether.
Swift SVN r13741
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
Have SILType::subst and SILFunctionType::subst always visit the interface types of a SILFunctionType. Fix up some problems in the specializer this exposed by having it correctly apply interface type substitutions to the function type of a specialized function and contextualized substitutions to the body.
Swift SVN r13714
The need to hide Self from AllArchetypes of a GenericParamList is (almost) defined away by @cc(witness_method); IRGen now knows how to do the right thing for witnesses regardless of their generic signature. Eliminating this special case from the AST allows us to clear up a bunch of ugly hacks that piled up elsewhere to try to accommodate that special case, and makes the prospect of moving IRGen's PolymorphicConvention to interface types more manageable.
We do need an unfortunate hack to suppress emitting associated archetypes of Self when considering an archetype as the polymorphic source for a witness, since we can't actually pass those through the witness CC without breaking ABI compatibility between generic signatures.
Swift SVN r13663
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
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
method type was handled earlier. This commit handles associated_type,
associated_type_protocol and base_protocol. We still need to parse
SpecializedProtocolConformance and InheritedProtocolConformance.
rdar://15722175
Swift SVN r13399
This is going to be useful so we can use a TypeLowering cache on SILType to ensure that both SILType::isTrivial and SILType::isAddressOnly do not have to perform the lookup of their TypeLowering which is slow. This will be coming later in the week.
Swift SVN r13374
which is the address of the string data. Have SILGen compute and produce the
isASCII bit as an integer literal, and remove the logic from IRGen.
This overall approach is simpler and enables better SIL-level optimizations.
Swift SVN r13363
SILGenApply is just one such place where this needs to happen;
instead, make it happen when computing the type of a SIL constant,
which applies far more generally.
Swift SVN r13305
It's OK to clone shared definitions, and we need to in order to carry non-inlined specializations with the transparent functions that reference them.
Swift SVN r13288
Introduce a new AST node to capture the covariant function type
conversion for DynamicSelf. This conversion differs from the normal
function-conversion expressions because it isn't inherently type-safe;
type safety is assured through DynamicSelf.
On the SIL side, map DynamicSelf down to the type of the declaring
class to keep the SIL type system consistent. Map the new
CovariantFunctionConversionExpr down to a convert_function
instruction, slightly loosening the constraints on convert_function to
allow for this (it's always been ABI-compatible-only conversions
anyway).
We currently generate awful SIL when calling a DynamicSelf method,
because SILGenApply doesn't know how to deal with the implicit return
type adjustment associated with the covariant function
conversion. That optimization will follow; at least what we have here
is (barely) functional.
Swift SVN r13286
Introduce a new AST node to capture the covariant function type
conversion for DynamicSelf. This conversion differs from the normal
function-conversion expressions because it isn't inherently type-safe;
type safety is assured through DynamicSelf.
On the SIL side, map DynamicSelf down to the type of the declaring
class to keep the SIL type system consistent. Map the new
CovariantFunctionConversionExpr down to a convert_function
instruction, slightly loosening the constraints on convert_function to
allow for this (it's always been ABI-compatible-only conversions
anyway).
We currently generate awful SIL when calling a DynamicSelf method,
because SILGenApply doesn't know how to deal with the implicit return
type adjustment associated with the covariant function
conversion. That optimization will follow; at least what we have here
is (barely) functional.
Swift SVN r13269
Have SILGen mark all variables bound from pattern bindings without initializers (and *only* ones without initializers) with mark_uninitialized [var] pseudo instructions. On the DI end, *only* consider mark_uninitialized instructions for DI analysis. This has many benefits:
- DI doesn't waste time analyzing locals that are trivially initialized in the original source code.
- DI doesn't try to mangle canonical SIL that has been inlined from transparent functions, which may have been optimized into a form DI isn't written to understand.
While we're here, fix an issue with DCE where it would try to kill unused MarkUninitialized instructions. Although MarkUninitialized has no side effects, it still is semantically important to raw SIL, and can't be killed.
Chris did most of the work here; I just finished updating tests and fixing bugs.
Swift SVN r13247
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
When a let decl is in an @objc class, it is converted to StoredObjC
storage. However, since it is not mutable, it should only have a getter
synthesized for it, not a setter.
Swift SVN r13096
type, so we emit them. Add mangler (and demangler) support for these.
Enhance our testcase to check to make sure that stores within these
specifiers are direct, they don't cause recursive infinite loops.
John, I picked w/W for the mangling letters, let me know if this is ok.
Swift SVN r13050
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
