1. Add new AccessScope type that just wraps a plain DeclContext.
2. Propagate it into all uses of "ValueDecl::getFormalAccessScope".
3. Turn all operations that combine access scopes into methods on AccessScope.
4. Add the "private" flag to distinguish "private" from "fileprivate"
scope for top-level DeclContext.
Quiz: What does @_transparent on an extension actually *do*?
1) Make all members @_transparent?
2) Allow your members to be @_transparent?
3) Some other magical effect that has nothing to do with members?
The correct answer is 1), however a few places in the stdlib defined
a @_transparent extension and then proceeded to make some or all members
also @_transparent, and in a couple of places we defined a @_transparent
extension with no members at all.
To avoid cargo culting and confusion, remove the ability to make
@_transparent extensions altogether, and force usages to be explicit.
Reimplement the witness matching logic used for generic requirements
so that it properly models the expectations required of the witness,
then captures the results in the AST. The new approach has a number of
advantages over the existing hacks:
* The constraint solver no longer requires hacks to try to tangle
together the innermost archetypes from the requirement with the
outer archetypes of the context of the protocol
conformance. Instead, we create a synthetic set of archetypes that
describes the requirement as it should be matched against
witnesses. This eliminates the infamous 'SelfTypeVar' hack.
* The type checker no longer records substitutions involving a weird
mix of archetypes from different contexts (see above), so it's
actually plausible to reason about the substitutions of a witness. A
new `Witness` class contains the declaration, substitutions, and all
other information required to interpret the witness.
* SILGen now uses the substitution information for witnesses when
building witness thunks, rather than computing all of it from
scratch. ``substSelfTypeIntoProtocolRequirementType()` is now gone
(absorbed into the type checker, and improved from there), and the
witness-thunk emission code is simpler. A few other bits of SILGen
got simpler because the substitutions can now be trusted.
* Witness matching and thunk generation involving generic requirements
and nested generics now works, based on some work @slavapestov was
already doing in this area.
* The AST verifier can now verify the archetypes that occur in witness substitutions.
* Although it's not in this commit, the `Witness` structure is
suitable for complete (de-)serialization, unlike the weird mix of
archetypes previously present.
Fixes rdar://problem/24079818 and cleans up an area that's been messy
and poorly understood for a very, very long time.
Allow it only to have one context parameter, whose ownership convention matches the convention of the resulting thick function, effectively limiting it to binding a closure invocation function to its context.
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.
While the use of a local property from within its own accessors is a
bit dubious, Swift 3 only warned on it, so model the existing lookup
behavior in the scope map.
Lazy property initializers can refer to 'self' either directly or
implicitly (via references to instance members). Model this in
ASTScope-based unqualified name lookup.
Note that the modeling of 'self' with the current name lookup
mechanism is broken, so when ASTScope-based unqualified name lookup is
enabled, it fixes SR-2203, rdar://problem/16954496, and the many dupes
of the latter.
ExprHandle is a relic from a horrible time when expressions made their
way into the type system via default arguments. It's been unnecessary
for a long time, so get rid of it.
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.
This function takes a substitution array and produces a
contextual type substitution map, so it is the contextual
type equivalent of GenericSignature::getSubstitutionMap(),
which produces an interface type substitution map.
The new version takes a GenericSignature, just like the new
getForwardingSubstitutions(), so that it can walk the
requirements of the signature rather than walking the
AllArchetypes list.
Also, this new version now produces a mapping from
archetypes to conformances in addition to the type mapping,
which will allow it to be used in a few places that had
hand-coded logic.
This is the first, and most trivial, usage of the new
GenericSignature::getSubstitutions() method.
Note that getForwardingSubstitutions() now takes a
GenericSignature, which is slightly awkward.
However, this is in line with our goal of 'hollowing out'
GenericParamList by removing knowledge of the finalized
generic requirements.
Also, there is now a new getForwardingSubstitutionMap()
function, which returns an interface type substitution
mapping. This is used in the new getForwardingSubstitutions()
implementation, and all also be used elsewhere later.
Finally, in the SILFunction we now cache the forwarding
substitutions, instead of re-computing them every time.
I doubt this makes a big difference in performance, but
it's a simple enhancement and every little bit helps.
- Make sure VarDecls have an associated TypeLoc, like ParamDecls do, then use it for printing the VarDecl's type.
This is done by moving ParamDecl's TypeLoc up to the VarDecl.
This is useful for being able to display the parameter names of function types embedded in VarDecls.
- Use the result TypeLoc of functions for printing. This enables printing parameter names of function types embedded in return types.
- Make sure to annotate attributes while they are printed.
Previously, if a generic type had a stored property with
a generic type and an initializer expression, we would
emit the expression directly in the body of each designated
initializer.
This is a problem if the designated initializer is defined
within an extension (even in the same source file), because
extensions have a different set of generic parameters and
archetypes.
Also, we've had bugs in the past where emitting an
expression multiple times didn't work properly. While these
might currently all be fixed, this is a tricky case to test
and it would be best to avoid it.
Fix both problems by emitting the initializer expression
inside its own function at the SIL level, and call the
initializer function from each designated initializer.
I'm using the existing 'variable initializer' mangling for this;
it doesn't seem to be used for anything else right now.
Currently, the default memberwise initializer does not use
this, because the machinery for emitting it is somewhat
duplicated and separate from the initializer expressions in
user-defined constructors. I'll clean this up in an upcoming
patch.
Fixes <https://bugs.swift.org/browse/SR-488>.
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.
If an inout parameter has an invalid type, we were unable to
distinguish it from a 'var' parameter, resulting in an invalid
diagnostic.
Fix this by adding a VarDecl::isInOut() flag, instead of
introspecting the type.
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')
* [Type System] Handle raw pointer conversion.
As proposed in SE-0107: UnsafeRawPointer.
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#implicit-argument-conversion
UnsafeMutablePointer<T> -> UnsafeMutableRawPointer
UnsafeMutablePointer<T> -> UnsafeRawPointer
UnsafePointer<T> -> UnsafeRawPointer
UnsafeMutableRawPointer -> UnsafeRawPointer
inout:
&anyVar -> UnsafeMutableRawPointer
&anyVar -> UnsafeRawPointer
array -> UnsafeRawPointer
string -> UnsafeRawPointer
varArray -> UnsafeMutableRawPointer
* Rename expectEqual(_, _, sameValue:) to expectEqualTest to workaround a type system bug.
<rdar://26058520> Generic type constraints incorrectly applied to functions with the same name
This is exposed by additions to the type system for UnsafeRawPointer.
Warning: unit tests fail very confusingly without this fix.
(in preparation for the private/fileprivate split)
An "access scope" is the outermost DeclContext where a particular
declaration may be referenced: for a 'fileprivate' declaration it's
the enclosing file, and for an 'internal' declaration it's the module.
'public' corresponds to a scope of "everything", represented by a null
DeclContext.
This model extends naturally to the (not-yet-implemented) SE-0025
notion of 'private', where the access scope is a declaration's
immediately enclosing DeclContext.
Complicating this model is the revised rules that allow, e.g., a public
declaration to be declared within an internal type. The access scope
for this declaration is still just the module, not "everything".
This commit reworks formal access control checking in terms of this
model, including tightening up some of the handling for '@testable'.
This implements the rule that you must be able to access a declaration's
type everywhere you can reference the declaration.
This was not intended to change compiler behavior, but in practice it
has made cross-file dependency tracking a bit more conservative
(unnecessarily), caught a mistake in diagnosing access violations,
and fixed a fuzzer-based crasher (see test changes).
Progress on SE-0025 ('private' and 'fileprivate')
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
(and any other member with higher access control than its enclosing type)
There's no effect, but it is now considered legal and the compiler will
no longer warn about it. This allows an API author to prototype their
API with proper access levels and still limit the top-level type.
If the new getEffectiveAccess computation turns out to be expensive, we
can cache the result.
Note that the compiler will still warn when putting a public member
inside an extension explicitly marked internal, because the extended
type could be public and then including a public member would be valid.
It is also still an error to put a public member inside a constrained
extension of an internal type, though I think this one is safe to
relax later.
Progress on SE-0025 ('private' and 'fileprivate')
Previously getInterfaceType() would punt to getType() if no
interface type was set. This patch changes getInterfaceType()
to assert if no interface type is set, and updates various
places to set the interface type explicitly.
This brings us a step closer to removing PolymorphicFunctionType.
First, enforce that the superclass of a class is an interface type.
Previously, Swift classes used interface types but imported
Objective-C generics used archetypes.
When the superclass type is always an interface type, we
can use the recently-added gatherAllSubstitutions() instead of
rolling our own parent type walk.
Also, this exposed an issue in name lookup where we would call
getSuperclass() on a type whose parent was an unbound generic.
This doesn't make sense, so generalize the existing check there.
