- Introduce a generic requirements opening function for type resolution,
which is used by the constraint system in cases where we need to
impose requirements on opened type variables.
- Refactor `replaceInferableTypesWithTypeVars` to use this function
when opening generic types that contain either placeholder or unbound
generic types.
Together these changes ensure that we don't drop generic requirements
when an unbound generic or placeholder type is used as a generic
argument.
Requirement opening relies on being able to query the opened type to
allow requirement fix coalescing to work. Record the opened type before
we open requirements to ensure we don't duplicate requirement fixes on
the base type with requirement fixes for the member.
This allows the `ExportContext` that is pre-computed for availability checking
to be reused when checking attached macro availability. Also, it just makes
more sense.
NFC.
This patch improves the warning for C++ APIs returning
`SWIFT_SHARED_REFERENCE` types but not annotated with either
`SWIFT_RETURNS_RETAINED` or `SWIFT_RETURNS_UNRETAINED` in the following
ways:
1. The warning for missing `SWIFT_RETURNS_(UN)RETAINED` annotations is
now emitted on Swift use sites, rather than while importing the API
(func/method decls).
- This logic is now implemented as a Misl Diagnostic in function
`diagnoseCxxFunctionCalls` in file lib/Sema/MiscDiagnostics.cpp.
- The warning is now triggered only when the API is actually used, which
reduces noise in large C++ headers.
- These warnings are still gated behind experimental-feature-flag `WarnUnannotatedReturnOfCxxFrt`
rdar://150800115
Resolving only a structural type meant we weren't checking generic
constraints, allowing invalid extensions to get past the type-checker.
Change to resolve an interface type.
To reduce code duplication, implement a convenience version of
`swift::recordRequiredImportAccessLevelForDecl()` that handles the common case
of recording required import access for a reference to a `ValueDecl`.
NFC.
If the argument type is an array and it's passed to an imported declaration
that accepts a raw pointer, the solver should use an "array-to-c-pointer"
conversion instead of the one for pointers.
Resolves: rdar://158629300
This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.
This fixes a runtime crash when a `weak` reference to a C++ foreign reference type is used.
Instead of a runtime crash, Swift would now emit a compiler error saying that `weak` keyword is incompatible with foreign reference types.
rdar://124040825 / resolves https://github.com/swiftlang/swift/issues/83080
Part of the Embedded Swift linkage model, this attribute ensures that
the function it applies to has a strong definition in its owning
module, and that its SIL is never serialized. That way, other modules
will not have access to its definition.
Implements rdar://158364184.
For a method key path use the locator for the apply itself rather
than the member, ensuring we handle invalid cases where the apply is
the first component, and providing more accurate location info.
Commit b70f8a82b1 introduced a usage of
ReplaceOpaqueTypesWithUnderlyingTypes in Sema. Previously this was only
called from SILGen.
The problem was that ReplaceOpaqueTypesWithUnderlyingTypes would call
getUniqueUnderlyingTypeSubstitutions(), which triggers a request to
type check the body of the referenced function.
While this didn't result in unnecessary type checking work, because
UniqueUnderlyingTypeSubstitutionsRequest::evaluate() would skip bodies
in secondary files, it did change declaration checking order.
The specific issue we saw was a bad interaction with associated type
inference and unqualified lookup in a WMO build, and a complete test
case is hard to reduce here.
However, no behavior change is intended with this change, modulo bugs
elsewhere related to declaration checking order, so I feel OK not adding
a test case.
I'll hopefully address the unqualified lookup issue exposed in the
radar soon; it has a reproducer independent of opaque return types.
Fixes rdar://157329046.
Some of the logic of `canOpenExistentialCallArgument` has to be
shared with constraint optimizer which does it's own validation
and most importantly - doesn't open overload choice type.
In order to share the logic between the solver and the optimizer,
let's extract checking that determines whether it's possible to
open existential argument into `canOpenExistentialAt`.
We still want to record this fix when falling back to type-checking
as a regular function body to ensure that in cases where there is a
disjunction of multiple result builders we favor the one that actually
supports the body.
The adjusted access level for the subscript shouldn't be fixed automatically
since sometimes the diagnostic is a warning and other times automatically
applying the fix-it immediately causes other errors, which can be confusing.
Resolves rdar://158261884.
If the parameter is `Any` we assume that all candidates are
convertible to it, which makes it a perfect match. The solver
would then decide whether erasing to an existential is preferable.
Resolves: rdar://157644867
Parameter type could be represented by an associated type which is
bound to a concrete type by an extension, `AbstractFunction::getType()`
should map it into context before returning because the construct is
that it always produces a function type.
Resolves: rdar://156955193
The invalid bit on PatternBindingDecl is very coarse grained, it
means any of the possible binding entries could be invalid.
Contextualization can handle invalid code anyway (e.g this is what we
do for `typeCheckBody`), so let's just avoid checking.
I don't recall why I made this conditional, let's just be consistent
and always set ErrorType for invalid AST. This should only affect
things like implicit nodes.
Rather than handling this in the callers of `typeCheckExpression`,
handle it in the constraint system's invalidation logic. This also
ensures we set a type for sub-pattern nodes.
I don't think this currently affects anything, but match what we do
for the expression and update the pattern if type-checking the
initialization fails.
