We allowed them for generic parameter inheritance clauses but
not anywhere else. While arguably this has stylistic benefits,
the restriction was not enforced consistently and was mostly a
result of implementation limitations.
Lift the restriction and fix things up where needed to make them
work. This brings us closer to allowing protocols to constrain
the 'Self' type to a subclass of a class by listing the class in
the protocol's inheritance clause, which was a feature from SE-0156,
but this doesn't quite work.
Fixes <https://bugs.swift.org/browse/SR-4678> and
<rdar://problem/31785092>.
These helpers are all about trying to decide if a particular overload
is "favored", but the answer won't change if a local archetype is
actually the type we're looking for, so there's no advantage to using
contextual types over interface types. On top of that, the calls to
mapTypeIntoContext are forcing the deserialization of several generic
environments that would have otherwise been left untouched, resulting
in unnecessary calls to the generic signature builder.
This isn't a recent change, but we're seeing strain around the generic
signature builder and complex constraints in the standard library
anyway, so we'll take wins where we can get them.
Discovered as part of the performance investigation in
rdar://problem/33984386.
We were checking the accessibility of the setter incorrectly.
As a result, a 'public internal(set)' property could not override
another 'public internal(set)' property; the setter had to be
public in the override, which is unnecessarily visible.
Fixes <rdar://problem/34085586>.
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.
A lazy property setter stores a value to the underlying storage
of the lazy property. The underlying storage is private, and it
is not proper for a public transparent function body to reference
a private member.
In practice, this only failed if the private member had a
non-constant offset, which only occurs with subclasses of @objc
classes, and resilient classes.
For @objc classes we already had a workaround where no accessors
for stored properties are ever transparent. I put this in to fix
this very issue with lazy properties, but now I realize it was
the wrong workaround, because we still had this problem with
resilient classes.
Note that I'm keeping the logic which made @objc accessors
non-transparent in place, because there's a good chance we will
decide that field offset globals should always be private.
Also, to make this issue reproducible in the test, I changed the
resilience execution tests to build the resilient library as a
dylib and link against that instead of just linking .o files
together. This is because .o files can see each other's internal
symbols, so I was not able to reproduce the original failure
this way. I went ahead and updated the other resilient tests to
do this as well. Also, each test now builds in WMO and non-WMO
mode, to exercise different SIL linking behavior. Again, the
WMO variant was needed to reproduce the issue fixed by this
commit, because without WMO we currently discard serialized SIL,
so no cross-module inlining of the lazy property setter was
taking place.
When dealing with explicit coercions apply their conversions
early to avoid searching for solutions with incorrect types,
and therefore prune search space.
Move disjunction selection logic one level up from the `solveSimplified`
which allows to simplify its logic and avoid collecting disjunctions
multiple times for each solver step.
Sort constraint components/buckets based on how many disjunctions
they have, that helps to prune some of the branches with incorrect
solutions early which limits overall depth of the search.
Resolves: SR-4714
"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'.
We don't want to print 'Self' here; the actual concrete type
is more useful.
NFC for now, but becomes important once a subsequent patch gives
'self' a DynamicSelfType in convenience initializers.
If we allow the right-hand type to be bound first, it can artificially
limit the options for the left-hand side, so attempt to delay binding of
the right-hand side types until after we've chosen something for the
left-hand side.
The test here will not fail without this change, but will fail without
this change if the ConstraintGraph.cpp changes from @xedin's edge
contraction patch (https://github.com/apple/swift/pull/11118) are
applied.
When search for potential bindings for the given type variable
encounters `DynamicTypeOf` constraint, its validation should use
representative type variable of the left-hand side instead of
direct comparison.
When trying to find bindings let's avoid type variables which
represent left-hand side of the `DynamicTypeOf` constraint,
because such type variables might be (implicitly) convertible to
[existential] metatype, but at the same time bound to something else
(e.g. Any), which fails when solver tries to simplify `DynamicTypeOf`
constraint itself.
In diagnoseUnintendedOptionalBehavior, guard against recursing into
non-single-expression closures. If we recurse into these, we can end
up hitting malformed ASTs that we do not expect. These happen when we
successfully type-check the code outside of the closure, but the
closure body has errors.
There are potentially other similar issues in other miscellaneous
diagnostics walks.
I opened https://bugs.swift.org/browse/SR-5758 to remind us to review
these and ensure they do not have similar issues.
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.
Previously, the failure diagnosis visitor would
default to the generic expr walk which would wind
up type checking the closure body and calling it a day.
Walk into the closure of a capture list expression to
emit better diagnostics.
A regression test for SR-5747 is added.
Limit the scope of the performance hacks which currently exist in the
solver even further by disallowing it to skip generic overlaods or stop
in case when previous solutions involve unavailable overloads, which
otherwise might lead to producing incorrect overall solutions.
Note that the bug was in Sema, but I added a SILGen test, since
that's an easy way to ensure the AST is valid.
Unfortunately the AST verifier does not perform many checks when
we emit diagnostics; adding the test case to an existing Sema test
would not catch regressions.
Fixes <rdar://problem/31595572>.
