Updates the message to use the type or ValueDecl instead of saying 'this' on 'Found this candidate' messages to provide more information where possible in selecting overloads
Per comment during draft iteration uses getInterfaceType and adds removeSelfParam to ValueDecl.t
Migrate to calling interfaceType and remove SelfParam
Update tests to reflect type information in ambiguity resolution
All but 5 tests now passing. Those 5 either do not refer to overloading errors or do pass even when modified to accept type specification
Move implementation to ValueDecl now that tests largely pass
All but 7 tests now passing. Those 7 tests either do not refer to these circumstances or do not seem to pass even when modified to accept type specifications.
Updates the message to use the type or ValueDecl instead of this on previous 'Found this candidate' messages
Note: doees not yet change all test cases so more tests are failing
Improve Diagnostic message on overload ambiguitiy
Remove messages that say 'found this candidate' in favour of providing the type for the candidate to aid in selection when the candidates are presented in a dialogue window.
Fix more tests
If there are no explicit concurrency attributes, isolated parameters,
or captures associated with the closure it should infer `nonisolated(nonsending)`
for the parent conversion injected by the solver (this conversion is injected
because the solver cannot check captures to elide it).
The change pushes `isIsolationInferenceBoundaryClosure` check down
with added benefit of getting preconcurrency context from the parent.
- Turn `BindExtensionsForIDEInspectionRequest` into the main extension
binding request.
- Change `ExtendedNominalRequest` such that it's no longer what
extension binding calls into to do the name lookup, instead it calls
directly into `computeExtendedNominal`. `getExtendedNominal` can
then be the entrypoint for `ExtendedNominalRequest` and assumes that
extension binding has already run. This avoids needing to fake the
dependency relationship in the DeclChecker.
This will mainly be useful once extension binding is fully
requestified, but even now it's a good idea to ensure module loading
isn't kicking name lookup.
The first bug is that we weren't computing isolation correctly for
nested defers. This is an unlikely pattern of code, but it's good to fix.
The second bug is that getActorIsolationOfContext was looking through
defers, but getActorIsolation itself was not. This was causing defer
bodies to be emitted in SILGen without an isolation parameter, which
meant that #isolation could not possibly provide the right value. Fixing
this involves teaching SILGen that non-async functions can have
nonisolated(nonsending) isolation, but that's relatively straightforward.
This commit doesn't fix #isolation or adequately test SILGen, but that'll
be handled in a follow-up.
This normally gets populated by successful type-checking, we still want
to populate it if we fail though to avoid attempting to type-check the
parent statement again.
We don't want to just check the first pattern, we're interested in
the first pattern that binds the given variable. That can be determined
by checking if it's canonical or not.
Now that we wire up the parents up-front, this no longer needs to
set the parents. As such, remove the logic and rename to reflect the
fact that it now just diagnoses mutability mismatches.
Rather than waiting until type-checking, we can set the parents
immediately when we create the CaseStmt. This requires fixing up
NamingPatternRequest to look at the recursive parent statement as
now the VarDecl may have a variable parent.
We don't wire up the parent variables until after type-checking, and
`recordInferredSwitchCasePatternVars` already handles joining the
pattern types, so we can remove this.
It could be that refTy->hasDynamicSelfType() is true whereas
varDecl->getValueInterfaceType()->hasDynamicSelfType() is false.
This happens if the base of the access is dynamic Self, so the
refTy is (Self) -> @lvalue Int or whatever.
Note that replaceDynamicSelfType() behaves correctly in this case;
it leaves that Self in place, because it's in contravariant
position.
However, the other place where we check the condition would then
form a nonsensical CovariantReturnConversionExpr around the result
of the access, even though no conversion was necessary here; the
type of the returned value does not involve Self.
Simplify this logic further with the correct condition.
Fixes rdar://159531634.
Declarations that are unavailable at runtime because of an `@available`
attribute referencing a custom domain that was imported `@_spiOnly` should be
hidden from public swiftinterface files in `-library-level=api` modules. For
remaining declarations that do get printed in the public swiftinterface, skip
printing any `@available` attribute that refers to the domains from those
`@_spiOnly` dependencies. This allows API developers to control declaration
visibility using availability defined by another module.
Resolves rdar://156512028.
Otherwise the "nonisolated nonsending by default" mode blows up as
distributed thunk signatures dont match expectations.
This undoes the fix from https://github.com/swiftlang/swift/pull/83940
and applies the fix on the synthesis side of the distributed thunks,
such that they are @concurrent always -- which keeps their old semantics
basically, regardless of what "default" mode we have.
This allows diagnostics to be more precise and will also support logic that
allows for special cases for `@available` attributes in exportability checking.
Also fixes a bug where the exportability of `@available` attributes attached to
extensions were diagnosed twice for slightly differing reasons.
Ttheir availability is going to match the property itself.
This is a workaround for lazy type-checking because synthesis
of accessors for such properties requires a reference to
`self` which won't be available because pattern binding
for the variable was skipped.
Resolves: rdar://129359362
Resolves: rdar://159463230
Resolves: https://github.com/swiftlang/swift/issues/84041
