- 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.
When macros like _SwiftifyImport are added to a wrapper module for a
clang module, they may need to refer to symbols declared in another
clang module that the wrapped module imports (e.g. because they are used
in the original signature). This adds all the imported clang modules as
implicit imports to the wrapper module.
rdar://151611573
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.
It should be possible to disable SerializationRequirement by assigning
Any to it. This effectively disables the checking, since any type
conforms to that.
Previously we would crash trying to check for this conformance; or
rather, emitting diagnostics about un-necessary casts then encountering
incomplete types in CSDiagnostics.
Avoiding the cast entirely sounds like a good solution here.
resolves rdar://159285863
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.
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
This type is only intended for pattern matching against `nil`
and the solver shouldn't early attempt to infer this type for
`nil` for arguments of `==` and `!=` operators it should instead
be inferred from other argument or result.
Resolves: rdar://158063151
This can help work around problems when the names of a C++ declaration
and a Swift declaration would collide, or to temporarily work around
compiler bugs.
rdar://152838988&140802127&158843666
When doing code completion it's entirely expected we'll end up with
ambiguities in the body of a closure if we're completing e.g
`someOverloadedFn(#^CC^#)`. As such we don't want to penalize the
solution for unbound type variables outside of the body since that
will prevent us from being able to eagerly prune e.g disfavored
overloads in the outer scope. This gives up to a 7% perf win in the
stress tester.
