In diagnostic mode, propagate function value placeholder/hole to
arguments and result. This helps to avoid recording extraneous
fixes because generic parameters and leading-dot syntax arguments
cannot be inferred in this case.
Instead of penalizing argument positions, let's increase the base
score for missing member fixes to make them more competitive in
situations where besides missing member other overloads have other
issues as well.
Resolves: rdar://169736579
If type variable that represents a type of a disjunction is
bound to a hole, consider disjunction to be solved. This
happens only when calls are completely broken.
Short-circuit calls where all arguments are invalid, otherwise the
solver would end up producing a solution for every overload which
it cannot disambiguate which quickly turns into "too complex" situation.
This teaches ClangImporter to represent a base class of a C++ foreign reference type as a Swift superclass if the base class is an FRT itself, and is a primary base class. Such base types are stored at offset zero within the derived type, which makes casting trivial.
This makes the following possible:
* casting an instance of derived FRT to base FRT explicitly with `as`
* passing an instance of derived FRT as a function parameter of type base FRT
* calling a method of base FRT on an instance of derived FRT without the compiler having to clone methods
Several constructs are not supported:
* downcasting, i.e. casting an instance of base FRT to derived FRT
* casting arrays/sets/dictionaries of FRTs
* casting to virtual bases
Support for casting to a base FRT that is not the primary base (not at offset zero) can be added in a follow-up change.
rdar://85881664 / resolves https://github.com/swiftlang/swift/issues/80231
When a nonisolated/@concurrent closure is passed to a
nonisolated(nonsending) parameter the solver has to be conservative
and produce a conversion that could be dissolved by actor
isolation checker when it determines that nonisolated(nonsending)
could be assumed onto the closure direct (i.e. when there are no
isolated captures involved), so let's not increase a score unless
closure states it's isolation explicitly to avoid picking a subpar
solution.
HiddenType is a new TypeBase subclass that carries a mangled name
without leaking the actual type definition. It serves as a type-slot
placeholder for stored-property types that have been elided from a
serialized binary module, so that the client side can either
(1) resolve this mangled name to the real type if the client has access to the owning module, or
(2) use the mangled name as a key to query abstract layout information also serialized in the binary module.
As an example — a library with a hidden field of a bridging-imported type:
```
// Utility.h (internal bridging header)
// typedef struct { int value; } Wrapper;
public struct S {
private var w: Wrapper
public var weight: Double
}
In the serialized module, the client's view reconstructs as:
public struct S {
private var w: @_hidden("$sSo7Wrappera")
public var weight: Double
}
```
Adds a new DynamicMemberLookupSubscriptRequest type for evaluating and
caching the validity of a `SubscriptDecl`'s usage to fulfill a
`@dynamicMemberLookup` requirement for a specific usage.
Adds support for `SubscriptDecl`s to fulfill `@dynamicMemberLookup`
requirements if they have additional arguments after `dynamicMember:` so
long as those arguments have default values, or are variadic.
This allows exposing values like `#function`, `#fileID`, `#line`, etc.
to dynamic member lookup.
`SubscriptDecl` exposes eligibility for `@dynamicMemberLookup`
requirements directly, so the `TypeChecker` interface for these members
can be replaced.
`SubscriptDecl`s may get checked multiple times for eligibility in
fulfilling `@dynamicMemberLookup` requirements; since the checks are
non-trivial and the result doesn't change, this eligibility can be
cached in the decl's `Bits`.
C++ types that are non-copyable and non-movable are not imported into Swift.
Variables of such types are marked as invalid in Swift by ClangImporter, however, compilation still proceeds without emitting any errors, unless the user attempts to use the problematic type from Swift. This differs from pure-Swift where having invalid decls are not allowed.
This adjusts the typechecker to account for the fact that a declaration coming from Clang might be invalid and not diagnosed at the same time. Instead of crashing in SILGen, let's emit a typechecking error.
rdar://137880350
If the argument was synthesized by the solver, let's fail. This can
happen when a parameter type is optional and (currently) inference
would try both optional and non-optional bindings for the new
argument which cases a mismatch in one of the conversion cases.
Resolves: https://github.com/swiftlang/swift/issues/88456
Resolves: rdar://174723056
This is a partial revert of https://github.com/swiftlang/swift/pull/87360
The change attempted to infer a concrete thrown error type onto
the closure but that leads to incorrect solutions when closure is
passed as an argument to an overloaded declaration because the
solver doesn't check whether calls in the body do throw the
expected type even with `FullTypedThrows` feature enabled
and so the safest option is still to assume un-typed `throws`
unless typed throws comes from a concrete contextual type.
Resolves: rdar://173132715
This erasure requires a function conversion and a heap allocation
so if there is an overload that adopted typed throws it should be
preferred over the one with regular `throws`.
Resolves: rdar://172779708
- rdar://169975618 ([nonescapable] Type conversion for function types with lifetime dependencies)
- rdar://160970376 ([nonescapable] [type checker] [source compat] protocol requirements should require matching methods signatures, including @lifetime)
The previous logic was relying on doing `coerceCallArguments` with the
full argument list instead of only the non-trailing args, and wasn't
handling the non-shorthand-init case. Update the logic to fix-up the
apply during the pre-walk, ensuring it gets applied consistently.
rdar://170076966
These will be used internally by the type checker to represent bindings
that are the joins and meets of types involving type variables. They
will not appear anywhere outside of the bindings code---so you won't
see them in expressions, or matchTypes(), etc.
A type variable that represents the type of a closure can only be bound
to a function type, but this fact is not directly encoded in the
constraint system.
Check for the appearance of a non-sensical subtype binding on a closure
type variable in reduceBinding(), and promote the binding to exact as
soon as we detect this, since binding the type will always fail; we want
to fail as quickly as possible, before attempting any more disjunctions.
This is a generally good performance optimization, and it also addresses
a performance regression from "Sema: Filter bindings by considering
conformance constraints".
This also speeds up the expression from rdar://59008707, which also uses
Combine and is slow for similar reasons.
If common result type optimization binds the type variable
representing the member chain result before we attempt an
overload from the corresponding disjunction, the
UnresolvedMemberChainBase constraint would fail.
The specific situation this would occur was when the extension
declared overloaded members with a concrete return type instead
of Self, and then this method was part of a chain:
extension P where Self == S {
func f(_: Int) -> S { ... }
func f(_: String) -> S { ... }
func g()
}
... foo(.f(3).g()) ...
The TestNoDoubleVoidClosureResultInference were actually not
exercising the code path they were supposed to because we
didn't check for that locator kind in getImpliedResultConversionKind().
Code with Protocol Composition parameters had not been taking into account
that a parameter would conform to all protocols in the composition on
member resolution and could fail to find a member for one protocol
on static lookups, resulting in a diagnostic that was incorrect even on
correct programs.
For example
```protocol P {
static var boo
}
protocol Q {
}
func t<T: P&Q>(x: T) { }
t(.boo)```
Diagnostic of Q does not have member boo
(Yes, other diagnostics are required in this code)
This occured because P and Q were considered one path at a time.
After the change, the P&Q path is considered together instead.
This replaces #87114, aligning the `BorrowingSequence` protocols and
related types to the Swift Evolution proposal, and without included
reparenting of `Sequence`.
If a partial application captures any non-`SendableMetatype` type parameter,
then it can call methods that are isolated to the current context and so the
function value cannot be `@Sendable`.
Resolves: rdar://170475422
Pavel Yaskevich
Egor Zhdan
Xi Ge
Slava Pestov
Itai Ferber
Konrad Malawski
Kathy Gray
Pavel Yaskevich
Aidan Hall
Hamish Knight
Aidan Hall
Alfonso Urdaneta
elsa
Elsa Keirouz
Nate Cook