This doesn't appear to be necessary when name lookup
does the right thing.
We don't *want* Sema to consider overload sets
containing both a protocol requirement and a witness,
because this could lead to exponential behavior.
When performing a lookup into a class C, we might find a member of
C that witnesses a requirement in a protocol Q that C conforms to.
In this case, AST name lookup returns both results.
There are two further levels of fitering which can eliminate the
ambiguity:
- Sema name lookup maps requirements to witnesses if the base type
of the lookup is a nominal type or a class-constrained archetype.
Imported conformances don't have this mapping recorded, but there's
another hack in this code path where if a requirement maps to
itself inside a conformance, it is dropped from the results
altogether.
- If the duplicate results were not filtered out in Sema name lookup,
there was another hack in CSRanking which would a witness higher
than it's requirement when comparing solutions. This doesn't work
for imported conformances, but usually name lookup filters out
the duplicate results sooner, which also eliminates the exponential
behavior from having multiple constraint system solutions.
However, if we have a subclass existential C & P where C conforms
to Q and we find a member of C that witnesses a requirement of Q,
then (C & P) does not conform to Q.
So if the conformance was imported, *both* of the above checks
would fail to disambiguate the witness and requirement, and the
member access would fail to type check.
To make this work with imported conformances, teach Sema name lookup
to extract the superclass from an existential before performing the
conformance check. If the conformance check fails, it means we
found the protocol member via the 'existential' part of the subclass
existential (eg, in our case, a member of P), and we proceed as
before.
Fixes <rdar://problem/33291112>.
It looks like this is covered by the witness lookup below.
Kind of a useless change, but I'm trying to simplify the
LookupResultBuilder as much as I can.
Fixes a problem related to presence of InOutType in function parameters
which diagnostics related to generic parameter requirements didn't handle
correctly, and improves diagnostics for unsatisfied generic requirements
in operator applications, which we didn't attempt to diagnose at all.
Resolves: rdar://problem/33477726
* Generate libSyntax API
This patch removes the hand-rolled libSyntax API and replaces it with an
API that's entirely automatically generated. This means the API is
guaranteed to be internally stylistically and functionally consistent.
A generic signature like <T : SomeClass> would create
a subtype constraint between the type variable for T and
SomeClass. This is too loose, because a subclass existential
like 'SomeClass & SomeProto' is a subtype of SomeClass, but
cannot bind to T, because it is not representationally a
single retainable pointer.
Fixes <rdar://problem/32617814>, <https://bugs.swift.org/browse/SR-5142>.
Inheritance of a protocol from JavaScriptCore's JSExport protocol is
used to indicate that the methods and properties of that protocol
should be exported to JavaScript. The actual check to determine
whether a protocol (directly) inherits JSExport is performed via the
Objective-C runtime. Note that the presence of JSExport in the
protocol hierarchy is not sufficient; the protocol must directly
inherit JSExport.
Swift warns about redundant conformance requirements and eliminates
them from the requirement signature (and, therefore, the Objective-C
metadata). This behavior is incorrect for JSExport, because the
conformance is actually needed for this API to work properly.
Recognize a protocol's inheritance JSExport specifically (by
name) when computing the requirement signature of the protocol. When
we find such a redundancy, suppress the "redundant conformance
constraint" diagnostic and add a new (hidden) attribute
@_restatedObjCConformance(proto). The attribute is used only by Objective-C
protocol metadata emission to ensure that we get the expected metadata
in the Objective-C runtime.
Fixes rdar://problem/32674145.
If class property with the same name has been found on both subclass and superclass,
let's always prefer subclass with all else equal, because subclass property
could only be found if requested directly.
Resolves: rdar://problem/32973206
* Make Decodable synthesis lazy again
* Remove side effects from assertions
* Assert on superclass failable initializers (and verify via a unit test)
* Fix space typo
* Remove more needless instances of single-element arrays
* Unambiguously refer to init() in unit tests
* Add failable superclass init tests and a test to ensure Decodable fails to be inherited when superclass synthesis fails
* Add tests for structs to ensure they receive no-argument initializers where appropriate
* Update usage checking to account for __shared parameters as immutable
* Allow pattern type checking to resolve Shared parameters to the appropriate parameter specifiers
* Add the __shared protocol requirement restriction
We break name lookup circularities by special-casing validation of
type aliases, resolving the underlying type of the type alias before
building the generic environment of the protocol that contains the
type alias.
However doing this gives the type alias an underlying type written
in terms of unresolved DependentMemberTypes which do not map to
associated types.
Attempting to substitute such a type fails.
We worked around this by re-validating type alias members of
protocols when we finally got around to building the protocol's
generic environment. Force this to happen earlier in
substMemberTypeWithBase(), because we need the fully resolved
underlying type in order to perform the substitution.
Also, fix TypeAliasDecl::setUnderlyingType() to only create a new
NameAliasType the first time it is called. In this special case
where it can be called twice with a resolved underlying type the
second time, we should not be creating a new NameAliasType.
There are better fixes possible here, requiring various levels
of refactoring. I'll investigate this soon, but for now this narrow
fix should address the problem with minimal risk.
Fixes <rdar://problem/33189068>.
just for pointer identity.
The current technique for deciding whether that's the case is *extremely*
hacky and need to be replaced with an attribute, but I'm reluctant to
take that on so late in the schedule. The hack is terrible but not too
hard to back out in the future. Anyone who names a method like this just
to get the magic behavior knows well that they are not on the side of
righteousness.
rdar://33265254
Currently we have a number of unsolved disjunctions hard-coded to 5,
which breaks some existing code by terminating shrinking too early.
This patch makes it a command-line option so users have control over
what that threshold can be.
Resolves: rdar://problem/33433595
* Use `isSpecificProtocol` instead of `==`
* Synthesize Encodable implementation lazily
* Don’t mark conformances as Used when they don’t need to be
* Avoid creating explicit one-element arrays
* Use lookupDirect instead of walking AST manually
* Produce diagnostic for Decodable classes whose non-Decodable superclass has a failable init
* Filter lazy vars manually since getStoredProperties() does not always do so
* Amend Decodable class diagnostic text
* Check for enum RawType errors only if the type was already validated
* Update unit tests to match changes
Classes which inherit from Codable classes inherit their Codable implementation (as opposed to synthesizing their own). In cases where they add their own storage, they will fail to inherit their superclass’s init(from:). In this case, we provide a diagnostic suggesting that init(from:) be overridden.
Classes which receive a synthesized Decodable implementation should be able to subclass non-Decodable classes (if the superclass has an accessible init()) method.
Also improve diagnostics when this is not the case.
A 'defer' parses as a DeferStmt and an implicit FuncDecl. The
implicit FuncDecl does not have a valid source location, so
be sure to consistently use the outer function's source
location instead.
Fixes <rdar://problem/33353035> / <https://bugs.swift.org/browse/SR-5464>.
