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.
Correct several behaviors of availability checking in unavailable contexts that
were inconsistent with the checking model:
- Avoid diagnosing unintroduced and obsolted declarations in contexts that are
unavailable in the same domain.
- Diagnose unavailability normally in type signature contexts.
