In the constraint solver, we've traditionally modeled nested type via
a "type member" constraint of the form
$T1 = $T0.NameOfTypeMember
and treated $T1 as a type variable. While the solver did generally try
to avoid attempting bindings for $T1 (it would wait until $T0 was
bound, which solves the constraint), on occasion we would get weird
behavior because the solver did try to bind the type
variable.
With this commit, model nested types via DependentMemberType, the same
way we handle (e.g.) the nested type of a generic type parameter. This
solution maintains more information (e.g., we know specifically which
associated type we're referring to), fits in better with the type
system (we know how to deal with dependent members throughout the type
checker, AST, and so on), and is easier to reason able.
This change is a performance optimization for the type checker for a
few reasons. First, it reduces the number of type variables we need to
deal with significantly (we create half as many type variables while
type checking the standard library), and the solver scales poorly with
the number of type variables because it visits all of the
as-yet-unbound type variables at each solving step. Second, it
eliminates a number of redundant by-name lookups in cases where we
already know which associated type we want.
Overall, this change provides a 25% speedup when type-checking the
standard library.
When checking a conformance of a concrete type to a protocol, we
effectively checked the associated types twice -- once when
deriving them, and another time at the end, where we performed
a substitution of the protocol 'Self' type to the concrete type.
The latter checked superclass constraints, while the former did not.
However, this trick no longer works with minimized generic
signatures, because <P : Self> no longer has redundant requirements
for the associated types of 'P'.
Instead, check superclass constraints at the same time as checking
conformances.
We still do a global lookup for operators even though they are
syntactically declared within types now, so for dependency-tracking
purposes continue to treat that as declared at the top level.
This isn't where we actually want to be---ideally we can use the types
of the arguments to limit the dependencies to a member lookup (or pair
of member lookups)---but since the operator overloads /themselves/
participate in type-checking an expression, I'm not sure that's 100%
correct. For now, it's better to be conservative. (This means
dependency analysis for operators remains as lousy as it was in Swift
2, but it's not a regression.)
rdar://problem/27659972
String literal expressions, as well as the magic literals #file and
tuple value that is then fed into one or two call expressions. For
string literals, that tuple value was implicitly splatted, breaking
AST invariants.
Instead, keep string literals and these magic literals that produce a
string as a single expression node, but store the declarations that
will be used to transform the raw literal into the complete
literal. SILGen will form the appropriate calls. This representation
is far simpler---the AST no longer has a bunch of implicit nodes---and
doesn't break AST invariants.
(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')
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
There's no longer anything looking up any conformances on Int and
getting negative results. Previously this was in looking for viable
'~=' overloads for the 'case' on line 206, but that seems to be
ruled out by other means now. We still have CHECK lines for other
protocol conformance checks, so we're not losing coverage here.
rdar://problem/25890224
a generic function type during constraint solving, as opposed to
checking a bunch of implicit things that we already know. This
should significantly improve the efficiency of checking uses of
generic APIs by reducing the total number of type variables and
constraints.
It is becoming increasingly funny to refer to this minimized generic
signature as the "mangling" signature.
The test changes are kind of a wash: in one case, we've eliminated
a confusing extra error, but in another we've caused the confusing
extra error to refer to '<<error type>>'. Not worth fighting right
now. The reference-dependencies change is due to not needing to
pull in all of those associated types anymore, which seems correct.
Extend the use of
_ObjectiveCBridgeable._unconditionallyBridgeFromObjectiveC to all
bridged types rather than using the custom entry points. Note that
there is a lot of hackery around ensuring that the conformance is
correct, because Sema needs to anticipate that SILGen (or later SIL
passes) might need those conformances. This primarily affects the
overlays, but with generalized bridging that means any mixed
Objective-C/Swift framework with bridged types.
Now that WitnessChecker is separate from ConformanceChecker, implement
a DefaultWitnessChecker subclass which performs default witness
resolution.
This populates the recently-added ProtocolDecl::DefaultWitnesses map.
Unlike ConformanceChecker, the DefaultWitnessChecker looks up the witness
in any protocol extensions of the protocol, matching the context archetypes
of the requirement against the witness.
For now, we infer default witnesses for all protocols, but don't do
anything with that information. An upcoming SILGen patch will start to
emit thunks and add tests.
Fills in Chris's placeholder in feace85d5. I'm not quite sure why a private
subscript doesn't produce a non-cascading dependency right now, but this is
at least conservatively correct.
(For more infomation on dependencies, check out "Dependency Analysis.rst".)
'Ss' appears in manglings tens of thousands of times in the standard library and is also incredibly frequent in other modules. This alone is enough to shrink the standard library by 59KB.
Swift SVN r32409
Also, checking protocol conformances doesn't depend on any members, just the type.
We don't track dependencies on types separately from members right now, though,
so instead there's now a dummy dependency on 'deinit'.
Swift SVN r30288
There's now a difference between "this file provides a particular type" and
"this file provides members on a particular type". Adding a conformance in
an extension is still considered "providing a type" because it can affect
things besides just lookups.
This modifies the swiftdeps file output (including the members used by a file),
but the driver hasn't been updated to take advantage of this yet.
Swift SVN r30285
- (depends|provides)-top-level for top-level names.
- (depends|provides)-nominal for access into nominal types.
- (depends|provides)-dynamic-lookup for @objc members available on AnyObject.
- depends-external for cross-module file-based dependencies.
No functionality change.
Swift SVN r30283
My 'declIsPrivate' predicate was too conservative: it saw a PatternBindingDecl,
didn't know what it was, and decided that meant it might not be private. Now it's
actually checking the decl kind and doing something reasonable for non-ValueDecls.
Swift SVN r30282
I think this is all working fine: we already say that a type adopting a
protocol depends on that protocol's members, and that an extension of a
protocol can supply members. It's a pretty conservative mechanism since
it doesn't take the constraints into account, but that's okay for now.
rdar://problem/20476867
Swift SVN r28475
