* [Typechecker] Allow enum cases without payload to witness a static get-only property with Self type protocol requirement
* [SIL] Add support for payload cases as well
* [SILGen] Clean up comment
* [Typechecker] Re-enable some previously disabled witness matching code
Also properly handle the matching in some cases
* [Test] Update typechecker tests with payload enum test cases
* [Test] Update SILGen test
* [SIL] Add two FIXME's to address soon
* [SIL] Emit the enum case constructor unconditionally when an enum case is used as a witness
Also, tweak SILDeclRef::getLinkage to update the 'limit' to 'OnDemand' if we have an enum declaration
* [SILGen] Properly handle a enum witness in addMethodImplementation
Also remove a FIXME and code added to workaround the original bug
* [TBDGen] Handle enum case witness
* [Typechecker] Fix conflicts
* [Test] Fix tests
* [AST] Fix indentation in diagnostics def file
This breaks source compatibility a little bit more than we'd like, so
reverting it for now.
Fixes <rdar://problem/57213598>.
This reverts commit 04fbcc0149.
Previously we did this as a last resort if inference fails. The new
behavior is technically source-breaking, but I suspect nobody
relied on the old behavior.
This can help avoid cycles by eliminating some unnecessary validation work.
Fixes <https://bugs.swift.org/browse/SR-11407>, <rdar://problem/54979757>.
If a protocol requirement has a type that's a nested member
type of another member type, eg,
protocol P {
associatedtype A : Q
func f(_: A.B)
}
Then we don't actually want to use 'f()' to infer the witness
for 'A'. By avoiding doing so, we eliminate some cycles which
can allow some programs to type check that didn't before.
* [TypeChecker] Enclosing stubs protocol note within editor mode
* [test] Removing note from test where there is no -diagnostics-editor-mode flag
* Formatting modified code
* [tests] Fixing tests under validation-tests
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
This reverts commit c725660cc9. It
uncovered a use-after-free in the GenericSignatureBuilder. Apologies
for the lack of a test case here; I'm still looking for something
small enough to commit.
Fixes rdar://problem/46772328.
Instead of trying to order based on the "nested depth", let's
always prefer canonical ordering of type parameters when it comes
to picking representative equivalence class.
Resolves: rdar://problem/45957015
Associated type inference can synthesize type aliases with the same name
as a generic parameter. This is all fine since the underlying type of
the alias is the generic parameter type, however it might have been
synthesized in a constrained extension, resulting in bogus diagnostics
that depend on the order in which declarations are type checked, which
can vary between WMO and non-WMO, different batch mode settings, etc.
Instead, let's just check the generic parameter list first.
Fixes <rdar://problem/22587551>, <rdar://problem/44777661>.
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>.
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.
For explicit abstract protocol floating requirement sources, get the source location from the protocol requirement rather than delegating to the parent `RequirementSource`.
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>.
