We can use a cheaper check; instead of transforming both types and
replacing any type parameters with their anchors, instead just
check if both map to the same equivalence class.
This also fixes a bug, even though it shouldn't, but I'll take it.
Fixes <rdar://problem/35756206>.
In structural lookup mode, let's resolve protocol typealiases to
dependent member types also. This is because areSameType() has
no way to see if a type alias is going to be equal to another
associated type with the same name, and so it would return false,
which produced ambiguity errors when there should not be any.
This exposes a deficiency in how we diagnose same-type constraints
where both sides are concrete. Instead of performing the check on
the requirement types, which might be dependent member types that
later on resolve to concrete types, do the check on the actual
equivalence classes further down in the GSB instead.
However, this in turn produces bogus diagnostics in some recursive
cases where we add same-type constraints twice for some reason,
resulting in a warning the second time around. Refine the check by
adding a new predicate to FloatingRequirementSource for requirements
that are explicitly written in source... which is not what
isExplicit() currently means.
These two declarations are now equivalent:
protocol P : SomeClass { ... }
protocol P where Self : SomeClass { ... }
There's a long, complicated story here:
- Swift 4.2 rejected classes in the inheritance clause of a
protocol, but it accepted the 'where' clause form, even
though it didn't always work and would sometimes crash
- Recently we got the inheritance clause form working, and
added a diagnostic to ban the 'where' clause form, because
we thought it would simplify name lookup to not have to
consider the 'where' clause
- However, we already had to support looking at the 'where'
clause from name lookup anyway, because you could write
extension P where Self : SomeClass { ... }
- It turns out that despite the crashes, protocols with
'Self' constraints were already common enough that it was
worth supporting the existing behavior, instead of banning
it
Fixes <rdar://problem/43028442>.
An extension might have an extended nominal, even if the extended type
is an error type. This can happen if, for example, the type lookup was
ambiguous, because the declaration lookup more eagerly disambiguates.
This is fine, because even if we bind the extension to a nominal it's
okay to diagnose an error later. However, we do have to deal with this
case here by checking for an error type.
A better solution would be to ensure the extended type is always set
to something, even if we diagnosed an error while resolving it, because
we can always use the declared type of the extended nominal instead.
However when I tried that I ran into more problems, and I don't feel
like shaving this yak right now.
There's no need to instantiate archetypes in the generic environment
of the declaration being opened.
A couple of diagnostics changed. They were already misleading, and the
new diagnostics, while different, are not any more misleading than
before.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
When forming the default witness table for a resilient protocol, look
for default associated conformances as well. These are identified by
associated conformance requirements whose root associated type has a
default type. For such requirements, we look for a conformance and
record it as a default associated conformance.
Emit a warning in cases where we don't find such a conformance,
because the associated type and conformance *may* have been added
with the intent of being resilient, and we can't know. This warning
might be a terrible idea, but it is only enabled under
-enable-resilience (which itself is hidden) and fires in one only
place in the standard library (which seems legitimate), so we'll try
it for now.
@_nonoverride is the opposite of override, disabling all override checking
for the given declaration. This can be used to suppress diagnostics related
to declarations that are almost overrides but shouldn’t be or to
intentionally break the override chain; in each case, we’ll end up with
an overload rather than an override.
For explicit abstract protocol floating requirement sources, get the source location from the protocol requirement rather than delegating to the parent `RequirementSource`.
Use the declaration-based name lookup facilities to re-implement
ProtocolDecl::getInheritedProtocols(), rather than dynamically selecting
between the requirement signature and the inherited types. This reduces
dependencies for this computation down to basic name lookup (no semantic
analysis) and gives us a stable result.
Whenever we visit a declaration via the DeclChecker, add it to the
list of declarations to finalize. This makes sure that we can centralize
the notion of “finalize for SILGen” and that it will be called for
everything in the source file being processed.
These will never work properly because of phase ordering issues with
the current declaration checker design. Since we can always express
the same thing with the protocol inheritance clause instead, just
diagnose this as an error instead of trying to hack around it.
Fixes <rdar://problem/38077232>, <https://bugs.swift.org/browse/SR-5581>.
This is fix for a source compat regression from:
commit 790625ab5b
Author: Doug Gregor <dgregor@apple.com>
Date: Mon Mar 19 15:29:32 2018 -0700
Allow a witness's noescape parameter to match a requirement's escaping parameter
The regression is not severe but its easy enough to fix.
With the above change, it was possible for an optional requirement that did
not have a witness in Swift 4.1 to pick up a witness in Swift 4.2, because
the escaping/noescape mismatch prevented it from being considered in Swift 4.1.
If the new witness was not sufficiently visible, this caused a source
compatibility regression.
Work around this by discarding the witness if its not sufficiently
visible. In -swift-version 5, the hack expires, and we revert to the
stricter, more consistent behavior.
Fixes <rdar://problem/39614880>.
Otherwise, the initializer won't be inherited properly onto a
subclass, resulting in the base class being allocated instead of the
subclass when using Sub.init(from:).
https://bugs.swift.org/browse/SR-8083
