When type-checking a function or subscript that itself does not have generic
parameters (but is within a generic context), we were creating a generic
signature builder which will always produce the same generic signature as
the enclosing context. Stop creating that generic signature builder.
Instead, teach the CompleteGenericTypeResolver to use the generic signature
+ the canonical generic signature builder for that signature to resolve
types, which also eliminates some extraneous re-type-checking.
Improves type-checking performance of the standard library by 36%.
When type-checking a function or subscript that itself does not have generic
parameters (but is within a generic context), we were creating a generic
signature builder which will always produce the same generic signature as
the enclosing context. Stop creating that generic signature builder.
Instead, teach the CompleteGenericTypeResolver to use the generic signature
+ the canonical generic signature builder for that signature to resolve
types, which also eliminates some extraneous re-type-checking.
Improves type-checking performance of the standard library by 36%.
Previously we stored this inside each default argument
initializer context. This was overkill, because it is
the same for all default arguments in a single function,
and also insufficient, because initializer contexts are
not serialized and thus not available in SILGen when
the function is in a different module.
Instead store it directly inside the function and
serialize it.
NFC for now, since SILGen isn't using this yet.
The base mutability of storage is part of the signature, so be sure
to compute that during validation. Also, serialize it as part of
the storage declaration, and fix some places that synthesize
declarations to set it correctly.
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
Pushes __consuming through the frontend and extends existing
attribute-based diagnsotics to cover it. Unlike `nonmutating`,
__consuming is allowed in class methods, though it makes little
sense to put it there.
To remove some callers of 'is<InOutType>' after Sema, start using what will soon be a structural invariant - the only expressions that can possibly have 'inout' type are semantically InOut expressions.
In anticipation of future attributes, and perhaps the ability to
declare lvalues with specifiers other than 'let' and 'var', expand
the "isLet" bit into a more general "specifier" field.
The outside representation already went to a flat set of requirements;
make the internal representation match so we aren't tempted to use the
requirement signature as inputs to a generic signature.
Rather than pretend that the requirement signature of a protocol is a
full, well-formed generic signature that one can meaningfully query,
treat it as a flat set of requirements. Nearly all clients already did
this, but make it official. NFC
Using the attribute in this position is a relic from the Swift 2
days, and fixing it required letting invalid code fall through to
Sema instead of being diagnosed in Parse proper. Treat 'var'
in this position like 'let' by simply offering to remove it
instead of extracting it into a separate variable.
Push the getName method from ValueDecl down to only those types that are
guaranteed to have a name that is backed by an identifier and that will
not be special.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
This is a second revision of the patch -- instead of changing
getEffectiveAccess() to take an extra parameter, this changes
getFormalAccessScope() instead.
Fixes <rdar://problem/32592973>.
The -enable-testing flag makes ValueDecl::getEffectiveAccess()
say that internal declarations are public.
This would lead us to emit spurious diagnostics if a default
argument of an internal function referenced a private symbol,
for example, which is something we actually want to allow.
Hack around this by adding a new 'forLinkage' parameter to
getEffectiveAccess(). When this is false, we ignore the
-enable-testing flag, and only look for the @_versioned
attribute.
I'm not very happy with the fix, because it only compliates
the subtle behaviors of getFormalAccess(), getEffectiveAccess()
and getFormalAccessScope() further. But refactoring this is
a bigger change than I'm willing to put into swift-4.0-branch.
Fixes <rdar://problem/32592973>.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Protocol requirements involving same-type-to-Self constraints cannot
be witnessed by declarations in non-final classes that have the same
form of same-type requirement to the corresponding class type, because
it creates a soundness hole with subclasses:
protocol Q {
func foo<T: P>(_: T, _: T.T) where T.T == Self
}
class C: Q {
func foo<T: P>(_: T, _: C) where T.T == C {}
}
class D: C {
// in D, T.T == D does not hold
}
Warn about this in Swift 3 compatibility mode, error on it in Swift 4
mode. When possible, provide a note + Fix-It suggesting that the
same-type constraint might be weakened to a superclass constraint
(which works with subclassing).
Fixes rdar://problem/30398503.
The AST verifier was causing deserialization of generic environments,
which slows things down considerably and affects our ability to test
for laziness in deserialization. Prevent it from doing so---and only
do the extra checkig if something else deserialized the generic
environment already.
... except there are some cases where it happens through means that
are harder to control (e.g., the AST walker for patterns) that need
more thought.
