Kicking the interface type request of the base decl here is wrong
if the decl is e.g a `self` capture in a closure, since we'll be in
the middle of type-checking the closure. I'm planning on properly
fixing this by folding the lookup into the constraint system, but for
now let's at least avoid kicking the request if we don't have an enum
case or enum var. That at least prevents it from affecting cases where
e.g you're pattern matching against a property in a class.
We could potentially tighten up the checking here even further, but
that could potentially impact source compatibility for ambiguous
cases. I'd like to keep this patch low risk, and then deal with any
fallout as part of the pattern type-checking work.
rdar://146952007
Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
This predicate is meant to ask if the loweredType is equal to
`getLoweredType(pattern, formalType)` for *some* abstraction pattern.
If the formal type contained an opaque archetype, we performed a
different check, because we asked if loweredEqual is equal to
`getLoweredType(AbstractionPattern(formalType), formalType)`.
This caused a spurious SIL verifier failure when the payload of an
existential contained an opaque archetype, because we lower the
payload with the most general AbstractionPattern, so that
@thin metatypes become @thick, etc.
The regression test exercises this bug, and also another bug that was
present in 6.0 but was already fixed on main by one of my earlier
refactorings.
Fixes rdar://problem/138655637.
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
Adding `T == Int` to
G1 := <T where T: Equatable>
gives us
G2 := <T where T == Int>
which means that if I have this substitution map for G2:
S2 := { Int }
then `SubstitutionMap::get(G1, S2)` should give me this substitution map
for G1:
S2 := { Int, [Int: Equatable] }
But it didn't, instead returning a substitution map with an invalid
conformance.
The problem is that local conformance lookup alone cannot recover
`[Int: Equatable]` in this case, because there is no "concrete
conformance requirement" `[T == Int: Equatable]` recorded anywhere
in G2.
This is of course a legacy of the GenericSignatureBuilder. It would have
been better to not drop conformance requirements made concrete. But oh
well.
Fixes https://github.com/swiftlang/swift/issues/74465
Fixes rdar://130404629.
This implements support for autoclosures, closures and local functions
nested within a pack iteration for loop.
The combination of explicit closure expressions and pack expansion
expressions still needs some work.
Fixes#66917.
Fixes#69947.
Fixes rdar://113505724.
Fixes rdar://122293832.
Fixes rdar://124329076.
We don't expect to see type parameters that are not generic parameters
here, but dependent member types that wrap an ErrorType are fine, they
show up when a conformance had an invalid type witness.
Fixes the remaining example from https://github.com/apple/swift/issues/59384.
- Pass down the TypeResolution instance so we can get the generic
signature. This ensures we always use the correct signature in
SIL mode.
- Don't diagnose if the type contains error types.
If we fail to build a generic signature (or requirement signature of a
protocol) because of a request cycle or because Knuth-Bendix completion
failed, we would create a placeholder signature with no requirements.
However in a move-only world, a completely unconstrained generic
parameter might generate spurious diagnostics when used in a copyable
way. For this reason, let's outfit these placeholder signatures with
a default set of conformance requirements to Copyable and Escapable.
Requirement lowering only expects that it won't see two requirements
of the same kind (except for conformance requirements). So only mark
those as conflicting.
This addresses a crash-on-invalid and improves diagnostics for
move-only generics, because a conflict won't drop the copyability
of a generic parameter and expose a move-only-naive user to
confusing error messages.
Fixes#61031.
Fixes#63997.
Fixes rdar://problem/111991454.
Previously, if a request R evaluated itself N times, we would emit N
"circular reference" diagnostics. These add no value, so instead let's
cache the user-provided default value on the first circular evaluation.
This changes things slightly so that instead of returning an
llvm::Expected<Request::OutputType>, various evaluator methods take
a callback which can produce the default value.
The existing evaluateOrDefault() interface is unchanged, and a new
evaluateOrFatal() entry point replaces
llvm::cantFail(ctx.evaluator(...)).
Direct callers of the evaluator's operator() were updated to pass in
the callback. The benefit of the callback over evaluateOrDefault() is
that if the default value is expensive to constuct, like a dummy
generic signature, we will only construct it in the case where a
cycle actually happened, otherwise we just delete the callback.
(cherry picked from commit b8fcf1c709efa6cd28e1217bd0efe876f7c0d2b7)
