When a protocol closes off an associated type by tying it to a concrete
type (e.g., via a same-type constraint), allow associated type inference
to use that information to infer the associated type rather than
requiring the user to restate the obvious.
Fixes SR-6640.
During associated type inference, also look for default associated type
witnesses from overridden associated types, so that one need not
redeclare default associated types at every level in a protocol hierarchy.
Move associated type inference into its own class, to make this
code easier to understand/maintain/improve. Minor diagnostics changes
because we're properly passing uninference associated type declarations
to the "group" checker.
We allow definitions like this:
struct G<T> {}
typealias A = G
As a shorthand for
typealias A<T> = G<T>
A typealias like this cannot satisfy an associated type requirement
for the same reason that a generic typealias cannot satisfy an
associated type requirement, which was already handled.
Previously this would crash in the type checker or in IRGen.
This fixes a weird regression in a fixed compiler crasher from the
next patch.
Within the compiler, we use the term "layout constraint" for any
constraint that affects the layout of a type parameter that has that
constraint. However, the only user-visible constraint is "AnyObject",
and calling that a layout constraint is confusing. Drop the term
"layout" from diagnostics.
Fixes rdar://problem/35295372.
Associated type redeclarations occasionally occur to push around
associated type witness inference. Suppress the warning about redeclarations
that add no requirements (i.e., have neither an inheritance nor a
where clause).
If a class was introduced in an OS newer than the deployment target,
suppress the inference of @_staticInitializeObjCMetadata, because
the resulting eager initialization will crash when run on older OS's.
This is a stop-gap solution; we want the eager initialization code to
check availability before registering the class, but that requires more
effort.
Fixes the main part of SR-6203 / rdar://problem/35161939.
Now that we pass in the correct type metadata for 'Self', it is
sound for a class to conform to a protocol with a default implementation
for a method returning 'Self'.
Fixes <rdar://problem/23671426>.
As part of type witness inference, allow us to infer a generic parameter
as the type witness for an associated type, when the associated type has
the same name as the generic parameter.
We likely want the more-general rule that generic parameters are always
visible as members of their enclosing type, but I'll tackle that separately.
This works around an order dependency that affected the source
compatibility suite.
When an associated type declaration “overrides” (restates) an associated
type from a protocol it inherits, note that it overrides that declaration.
SourceKit now reports overrides of associated types.
If unqualified name lookup finds an associated type, but resolution to
the type witness fails, produce a diagnostic rather than silently
failing. Fixes the crash in SR-5825, SR-5881, and SR-5905.
It's conceivable that we could resolve this with suitably global
associated type inference... but that's far off and it's best not to
crash until then.
The type checker shouldn’t know about potential archetypes. Use
GenericSignatureBuilder::resolveEquivalenceClass() and perform the lookup
into that instead.
The test case change highlights an existing problem with generic signature
minimization.
The type checker shouldn’t know about potential archetypes. Use
GenericSignatureBuilder::resolveEquivalenceClass() and perform the lookup
into that instead.
The test case change highlights an existing problem with generic signature
minimization.
When computing the requirement signature of a protocol, eliminate requirement
sources that are self-derived by virtual of using a given requirement of
that protocol to prove that same constraint.
Nested-type-name-match constraints are odd because they are
effectively artifacts of the GenericSignatureBuilder's algorithm,
i.e., they occur when we have two PotentialArchetypes representing the
same type, and each of those PA's has a nested type based on the same
associated type. Because of this, nested-type-name-match constraints
have no useful requirement sources, so the normal means of detecting
self-derived constraints doesn't suffice, and we end up with
self-derived nested-type-name-match constraints eliminating the
constraints they depend on, causing spurious "redundant same-type
constraint" diagnostics and minimized generic signatures that drop
important requirements.
Handle nested-type-name-match constraints by first keeping them out of
the connected-components algorithm used to compute same-type
constraints within an equivalence class. Then, detect self-derived
nested-type-name-match constraints by determining whether any of the
ancestor potential archetypes are in the same equivalence class... and
redundant with the edge that makes the ancestor potential archetypes
equivalent. Remove such self-derived edges, and treat all other
nested-type-name-match edges as derived, providing a minimized
signature.
Fixes SR-5841, SR-5601, and SR-5610
Properties of Codable types which are optional and excluded via the CodingKeys enum should not require an explicit nil assignment, since in all other cases, optional vars get a default value of nil.
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.
We had two slightly different codepaths to diagnose ': class'
in an inheritance clause where it is not supported.
For generic parameters, we would fix the 'class' to 'AnyObject',
but for associated types we didn't do this. Perform the fix in
all cases where it makes sense and remove one of the two
diagnostics.
This also removes some dead code, where an early assert() ensures that
'strong' is never passed into the function, but then the function later
tries to handle 'strong'.
Finally, use a switch statement for future proofing.
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
Detect requirement sources that are internally self-derived for
(e.g.) handling of requirement sources for same-type constraints and
superclass constraints. This eliminates some incorrect warnings about
redundant same-type constraints involving recursive protocols, which
(more importantly) were a symptom of incorrect generic signature
minimization.
Fixes SR-5473.
More correctly fix SR-5485: we were retaining self-derived conformance
sources when we shouldn't, which led to spurious "redundant
conformance" diagnostics and (much worse) incorrect minimized generic
signatures. Now, when we detect a self-derived conformance source,
return the minimal source that will derive the same conformance... and
retain that one if it's new.
When determining whether a conformance requirement source is
self-derived, ignore the top-level "Self: P" requirement in a
requirement signature.
Fixes SR-5485 / rdar://problem/33360699.
Whenever we need a complete, well-formed potential archetype,
reprocess any delayed requirements, so that we pick up additional
requirements on that potential archetype.
This relies on us tracking a generation count for the GSB instance as
a whole, which gets bumped each time we add some new requirement or
create a new potential archetype, and only actually reprocessing
delayed requirements when the generation count exceeds the point at
which we last processed delayed requirements.
This gets the most basic recursive protocol constraint working
end-to-end and doesn't seem to break things.
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.
