The witnesses in a NormalProtocolConformance have never been
completely serialized, because their substitutions involved a weird
mix of archetypes that blew up the deserialization code. So, only the
witness declarations themselves got serialized. Many clients (the type
checker, SourceKit, etc.) didn't need the extra information, but some
clients (e.g., the SIL optimizers) would end up recomputing this
information. Ick.
Now, serialize the complete Witness structure along with the AST,
including information about the synthetic environment, complete
substitutions, etc. This should obsolete some redundant code paths in
the SIL optimization infrastructure.
This (de-)serialization code takes a new-ish approach to serializing
the synthetic environment in that it avoids serializing any
archetypes. Rather, it maps everything back to interface types during
serialization, and deserialization forms a new generic environment
(with new archetypes!) on-the-fly, mapping deserialized types back
into that environment (and to those archetypes). This way, we don't
have to maintain identity of archetypes in the deserialization code,
and might get some better re-use of the archetypes.
More of rdar://problem/24079818.
The reason we are using the parsing heuristic is to ensure that we do
not need to update a ton of test cases. This makes sense since in
general, when parsing we are creating new code that is running for the
first time through the compiler. On the other hand, in
serialization/deserialization we expect to get back exactly the
SILFunction that we serialized. So it makes sense to explicitly
preserve whether we have ownership qualification or not.
rdar://28851920
I had several versions of the copy value, destroy value patch and in one of them
I bumped the module file version number. The one I committed was not one of
those = /.
Sorry Jordan!
We don't want the machine calling conventions for closure invocation functions to necessarily be tied to the convention for normal thin functions or methods. NFC yet; for now, 'closure' follows the same behavior as the 'method' convention, but as part of partial_apply simplification it will be a requirement that partial_apply takes a @convention(closure) function and a box and produces a @convention(thick) function from them.
Sugared GenericTypeParamTypes point to GenericTypeParamDecls,
allowing the name of the parameter as written by the user to be
recovered. Canonical GenericTypeParamTypes on the other hand
only store a depth and index, without referencing the original
declaration.
When printing SIL, we wish to output the original generic parameter
names, even though SIL only uses canonical types. Previously,
we used to accomplish this by mapping the generic parameter to an
archetype and printing the name of the archetype. This was not
adequate if multiple generic parameters mapped to the same
archetype, or if a generic parameter was mapped to a concrete type.
The new approach preserves the original sugared types in the
GenericEnvironment, adding a new GenericEnvironment::getSugaredType()
method.
There are also some other assorted simplifications made possible
by this.
Unfortunately this makes GenericEnvironments use a bit more memory,
however I have more improvements coming that will offset the gains,
in addition to making substitution lists smaller also.
This lets us get to the goal of +0 guaranteed closure contexts. NFC yet, just add the under-the-hood ability for partial_apply instructions producing callee-guaranteed closures to be parsed, printed, and serialized.
It's the same thing as for alloc_ref: the optional [tail_elems ...] attribute specify the tail elements to allocate.
For details see docs/SIL.rst
This feature is needed so that we can allocate a MangedBuffer with alloc_ref_dynamic.
The ManagedBuffer.create() function uses the dynamic self type to create the buffer instance.
RequirementReprs stored serialized references to archetypes,
which do not have enough information to reconstruct same-type
requirements.
For this reason, we would serialize the 'as written' requirement
string as well as the actual types, which is a horrible hack.
Now that the ASTPrinter and SourceKit use GenericSignatures,
none of this is needed anymore.
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.
Long term, we want to refactor the AST to reflect the current
programming model in Swift. This would include refactoring
FunctionType to take a list of ParameterTypeElt, or something with a
better name, that can contain both the type and flags/bits that are
only specific to types in parameter position, such as @autoclosure and
@escaping. At the same time, noescape-by-default has severely hurt our
ability to print types without significant context, as we either have
to choose to too aggressively print @escaping or not print it in every
situation it occurs, or both.
As a gentle step towards the final solution, without uprooting our
overall AST structure, and as a way towards fixing the @escaping
printing ails, put these bits on the TupleTypeElt and ParenType, which
will serve as a model for what ParameterTypeElt will be like in the
future. Re-use these flags on CallArgParam, to leverage shared
knowledge in the type system. It is a little painful to tack onto
these types, but it's minor and will be overhauled soon, which will
eventually result in size savings and less complexity overall.
This includes all the constraint system adjustments to make these
types work and influence type equality and overload resolution as
desired. They are encoded in the module format. Additional tests
added.
The new instructions are: ref_tail_addr, tail_addr and a new attribute [ tail_elems ] for alloc_ref.
For details see docs/SIL.rst
As these new instructions are not generated so far, this is a NFC.
The new instructions are: ref_tail_addr, tail_addr and a new attribute [ tail_elems ] for alloc_ref.
For details see docs/SIL.rst
As these new instructions are not generated so far, this is a NFC.
We were optimizing away unused pattern binding initializer contexts in
both the parser and in semantic analysis, which led to a
somewhat-unpredictable set of DeclContexts in the AST. Normalize
everything by always creating these contexts.
Now that SILFunctions no longer reference a GenericParamList, we
don't need to de-serialize cross-module references to archetypes
anymore.
This was the last remaining usage of AllArchetypes, so we can
finally rip it out.
This patch is rather large, since it was hard to make this change
incrementally, but most of the changes are mechanical.
Now that we have a lighter-weight data structure in the AST for mapping
interface types to archetypes and vice versa, use that in SIL instead of
a GenericParamList.
This means that when serializing a SILFunction body, we no longer need to
serialize references to archetypes from other modules.
Several methods used for forming substitutions can now be moved from
GenericParamList to GenericEnvironment.
Also, GenericParamList::cloneWithOuterParameters() and
GenericParamList::getEmpty() can now go away, since they were only used
when SILGen-ing witness thunks.
Finally, when printing generic parameters with identical names, the
SIL printer used to number them from highest depth to lowest, by
walking generic parameter lists starting with the innermost one.
Now, ambiguous generic parameters are numbered from lowest depth
to highest, by walking the generic signature, which means test
output in one of the SILGen tests has changed.
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.
I don't see any tests failing with this code removed; I guess
either the duplicate archetype issue no longer occurs, or does
not matter since we use interface types almost everywhere
when talking about Decls from other modules.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
The isExplicitlyEscaping bit, though useful for printing,
unfortunately puts us in a position where we have different bit
patterns for the same type, and thus lose much of our type equivalence
checking for overriding, protocol conformance, etc., even if we were
to take subtyping into account. We need to drop it, relying on the
existing noescape bit alone to determine the type's semantics (at
least, as long as we continue to encode this information in the type
system).
This is a partial fix; we will now be excessively printing @escaping,
but the subsequent commits will correct this. For printing, we will
instead need to be more context-aware.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
In Swift, default arguments are associated with a function or
initializer's declaration---not with its type. This was not always the
case, and TupleType's ability to store a default argument kind is a
messy holdover from those dark times.
Eliminate the default argument kind from TupleType, which involves
migrating a few more clients over to declaration-centric handling of
default arguments. Doing so is usually a bug-fix anyway: without the
declaration, one didn't really have
The SILGen test changes are due to a name-mangling fix that fell out
of this change: a tuple type is mangled differently than a non-tuple
type, and having a default argument would make the parameter list of a
single-parameter function into a tuple type. Hence,
func foo(x: Int = 5)
would get a different mangling from
func foo(x: Int)
even though we didn't actually allow overloading.
Fixes rdar://problem/24016341, and helps us along the way to SE-0111
(removing the significance of argument labels) because argument labels
are also declaration-centric, and need the same information.
This module version belongs with:
commit c47687da2c
Author: Andrew Trick <atrick@apple.com>
Date: Fri Jul 15 13:04:02 2016
Add an isStrict flag to SIL pointer_to_address. (#3529)
This flag tracks whether we have a special kind of imported class
that has limitations in what you can do with it. Currently it's
used for two things: CF classes, and the magic "Protocol" class used
to represent Objective-C protocol metadata. I'm planning to add a
third to handle classes with the recently-added objc_runtime_visible
attribute, which describes an Objective-C class whose runtime symbols
are hidden (forcibly preventing categories and subclassing). This is
used for some of the types in Dispatch, which has exposed some of the
classes that were considered implementation details on past OSs.
I'm splitting the flag into an enum rather than just marking the
Dispatch classes with the existing flag because we still need to
be able to /cast/ to the Dispatch types (which you can't do with CF
types today) and because they deserve better than to be lumped in
with CF for diagnostic purposes.
Groundwork for rdar://problem/26850367, which is that Swift will
happily let you extend the new Dispatch classes but then fails to find
the symbols at link-time.
The next patch creates a situation where we serialize a reference
to a TypeAliasDecl's GenericParamTypeDecl, which references the
inner DeclContext of the TypeAliasDecl itself. This was not being
deserialized properly, triggering assertions.
not have access to their type arguments at runtime. Use this to
fix the emission of native thunks for imported ObjC-generic
initializers, since they may need to perform bridging.
For now, pseudo-genericity is all-or-nothing, but we may want to
make it apply only to certain type arguments.
Also, clean up some code that was using dead mangling nodes.
The verifier now asserts that Throws, ThrowsLoc and isBodyThrowing()
match up.
Also, add /*Label=*/ comments where necessary to make the long argument
lists easier to read, and cleaned up some inconsistent naming conventions.
I caught a case where ClangImporter where we were passing in a loc as
StaticLoc instead of FuncLoc, but probably this didn't affect anything.
...with a better message than the generic "older version of the
compiler" one, when we know it's actually a different version of
Swift proper.
This still uses the same internal module version numbers to check
if the module is compatible; the presentation of language versions
is a diagnostic thing only.
Speaking of module version numbers, this deliberately does NOT
increment VERSION_MINOR; it's implemented in a backwards-compatible
way.
This will only work going forwards, of course; all existing modules
don't have a short version string, and I don't feel comfortable
assuming all older modules we might encounter are "Swift 2.2".
rdar://problem/25680392
