It's okay if we're in the middle of associated type inference, as
long as we've already recorded the type witness we're looking for!
This fixes a regression from 62e4979691,
but what's notable is the cycle breaking hack has been there this
whole time. The fact that it was overly broad was only exposed now.
The specific code example in the test case is intentionally wrong.
It was reduced from a piece of code that attempted to refer to a
generic parameter named `Output` by writing `Self.Output`, and this
picked up a protocol type alias instead, so the original project
needed to be fixed anyway. But, the regressed behavior was bogus
too, because we started to emit a diagnostic that didn't make
sense, so let's fix it anyway.
Fixes rdar://problem/167849997.
We noticed that a project failed to build with prepared overloads enabled,
but built successfully with prepared overloads disabled.
It turns out that the code clearly should never have been accepted in the
first place, because the type checker was making an arbitrary choice between
two nominal type declarations with the same name.
Further inspection revealed this was because of a FIXME added in 2013 which
was far too broad. Tighten up the logic here to only disambiguate if at least
one of the two declarations is a type alias, and it has the same underlying
type as the other one. A choice between unrelated nominal type declarations
should always be ambiguous.
This still isn't perfect, because we might have two generic type aliases
that are referenced in both solutions with different substitution maps,
in which case we will still erroneously pick the first one. But this
is better than the old logic, at least.
Fixes rdar://165863775.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
The proposal states that this should work, but this was never
implemented:
protocol P<A> {
associatedtype A
}
struct S: P<Int> {}
- Fixes https://github.com/swiftlang/swift/issues/62906.
- Fixes rdar://91842338.
We have a special hack to infer the 'Failure' type witness in
'AsyncIteratorProtocol' by considering the type of 'next()'
witness.
In eaf06eae0e I added a check to
fix some assertions that could happen if 'next()' was witnessed
by a declaration in a protocol extension or superclass, which
has a different generic signature.
However my check was too narrow, because it also prohibited
this form of inference when 'next()' was in a different
extension of the same nominal type.
Allow this again.
Fixes https://github.com/swiftlang/swift/issues/79367.
Fixes rdar://problem/145341658.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of opaque types, instead
of disabling availability checking.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
