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
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
Override checking checks if the derived declaration's generic
signature is compatible with the base, but it does this after
doing a bunch of other checks which feed potentially invalid
type parameters to generic signature queries.
Now that the requirement machine is stricter about this kind
of this, re-organize some code to get around this.
Unfortunately this regresses a diagnostic, because we reject
candidates with mismatched generic requirements earlier in
the process.
I created a second copy of each test where the output changes
after disabling parser lookup. The primary copy now explicitly
calls the frontend with -disable-parser-lookup and expects the
new diagnostics; the *_parser_lookup.swift version calls the
frontend with -enable-parser-lookup and has the old expectations.
This allows us to turn parser lookup on and off by default
without disturbing tests. Once parser lookup is completely
removed we can remove the *_parser_lookup.swift variants.
This is technically a source break, but it was always a circularity
issue. It will compile fine in isolation, but all attempts to lookup
nested type via qualified lookup (e.g. witness matching) will re-enter
themselves and potentially produce inconsistent results.
Commit a regression test so we nail down this behavior to see if we can
revisit this.
Witness matching is a source of a lot of ad-hoc cycles, and mixes the
logic that performs resolution, caching, validation, and cycle detection into one
place. To make matters worse, some checkers kick off other checks in
order to cache work for further declarations, and access an internal
cache on their subject conformance for many requirements at once, or
sometimes just one requirement.
None of this fits into the request evaluator's central view of the
caching. This is further evidenced by the fact that if you attempt to
move the caching step into the evaluator, it overcaches the same
witness and trips asserts.
As a start, define requests for the resolution steps, and flush some
hacks around forcing witness resolution. The caching logic is mostly
untouched (the requests don't actually cache anything), but some cycle
breaking is now handled in the evaluator itself. Once witness matching
has been refactored to cache with the evaluator, all of these hacks can
go away.
My urge to destroy the LazyResolver outweighs the compromises here.
It is possible for getSuperclassDecl() to return a non-null type, while
getSuperclass() returns an ErrorType. In this case, getContextSubstitutions()
could crash because the walk of the superclass chain via getSuperclass()
might not find the context class.
Instead of crashing in asserts builds, let getContextSubstitutions()
silently build an invalid substitution map here, just as it does in no-asserts
builds.
getInterfaceType() will return an ErrorType if the declaration is currently
being validated, which can happen if override checking triggers associated
type inference.
I believe this is <rdar://problem/47220065>.
Resolve a cycle caused by overload resolution considering recursive
static candidates where before it would silently reject them. In
a world before the InterfaceTypeRequest, the overload resolution
machinery would attempt to validate the declaration and would recieve
a bad answer. This caused circular candidates to be ignored as a side
effect. This behavior was partially restored by the fixes in #27725 and #27668
but that isn't enough for recursive static variables. Even if it were,
the constraint fix kind doesn't make sense.
Luckily, the right answer is to just reject recursive static VarDecl
candidates entirely.
Addresses rdar://56410015
When member type lookup is rooted at a typealias, it should not be possible for that
lookup to see the typealias itself. This prevents recursively trying
to resolve the underlying type, which used to be silently ignored when
validateDecl bounced the caller back with an error type or a null type.
Addresses rdar://56411408
