Currently `getPotentialBindingsForRelationalConstraint` doesn't
respect the fact that type of key path expression has to be a
form of `KeyPath`, instead it could eagerly try to bind it to
`Any` or other contextual type if it's only available
information.
This patch aims to fix this situation by filtering potential
bindings available for type variable representing type of
the key path expression.
Resolves: SR-10467
Result of force unwrap is always connected to its base
optional type via `OptionalObject` constraint which
preserves l-valueness, so in case where object type got
inferred before optional type (because it got the
type from context e.g. parameter type of a function call),
we need to test type with and without l-value after
delaying bindings for as long as possible.
Resolves: rdar://problem/47967277
Original fix for SR-9102 stripped throws bit from the function types
nested inside optionals before attempting bindings, that doesn't
work with e.g. default parameter values because conversions from
throwing and non-throwing functions are only allowed in subtype
relationship but function types nested inside optionals are going
to be equated.
So this patch takes an alternative approach and attempts to pattern
match `nil` literal and `.none` use and classify argument as
non-contributing to throws.
Resolves: rdar://problem/47550715
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
I have a follow-up change to correctly classify optional arguments,
and with that fix applied we incorrectly emit rethrow diagnostics for
'nil' arguments passed in places where optional throwing functions are
expected.
This change ensures that we strip the throwing bit off of the nested
function type so that we don't consider 'nil' arguments in these
positions as potentially throwing functions.
- Use `int` instead of `unsigned int` to represent # of non-defaultable bindings.
Because the formula is `-(Total - Defaultable)` which could only be `0` or negative.
- Increase number of defaultable bindings iff the binding is accepted.
Make sure that presence of `@autoclosure` attribute handled
in one place - `matchCallArguments`, which makes it possible
to remove the rest of (now redundant) autoclosure related
logic scattered throughout solver.
When `bind param` constraint is associated with a given
type variable a set of bindings collected for it is
potentially incomplete, because binding gathering doesn't
look through related type variables. Which means that
such type variable has to be de-prioritized until
`bind param` constraint is resolved or there is just
nothing else to try, otherwise there is a risk that
solver would skip some of the valid solutions.
This only affects type variable that appears one the
right-hand side of the `bind param` constraint and
represents result type of the closure body, because
left-hand side gets types from overload choices.
Resolves: rdar://problem/45659733
* Implement dynamically callable types (`@dynamicCallable`).
- Implement dynamically callable types as proposed in SE-0216.
- Dynamic calls are resolved based on call-site syntax.
- Use the `withArguments:` method if it's defined and there are no
keyword arguments.
- Otherwise, use the `withKeywordArguments:` method.
- Support multiple `dynamicallyCall` methods.
- This enables two scenarios:
- Overloaded `dynamicallyCall` methods on a single
`@dynamicCallable` type.
- Multiple `dynamicallyCall` methods from a `@dynamicCallable`
superclass or from `@dynamicCallable` protocols.
- Add `DynamicCallableApplicableFunction` constraint. This, used with
an overload set, is necessary to support multiple `dynamicallyCall`
methods.
When `bind param` constraint is associated with a given type
variable a set of bindings collected for it is potentially
incomplete, because binding gathering doesn't look through related
type variables. Which means that such type variable has to be
de-prioritized until `bind param` constraint is resolved
or there is just nothing else to try, otherwise there is a
risk that solver would skip some of the valid solutions.
Resolves: rdar://problem/45659733
Improve enumerateDirectSupertypes so that for T? it will return U? if
U is a supertype of T. This is another form of direct supertype.
This is making up for a deficiency in the completeness of our Type
join implementation, which should be able to directly compute a join
of disparate types that share some common supertype, but sometimes
fails to in cases involving protocol compositions.
Fixes rdar://problem/45490737
There's no need to instantiate archetypes in the generic environment
of the declaration being opened.
A couple of diagnostics changed. They were already misleading, and the
new diagnostics, while different, are not any more misleading than
before.
`DisjunctionStep` attempts all of the viable choices,
at least one of the choices has to succeed for disjunction
to be considered a success.
`DisjunctionStep` attempts each choice and generates followup
`SplitterStep` to see if applying choice to constraint system
resulted in any simplification.
Introduce `TypeBinding` interface with a single `attempt` method
which is useful to encapsulate specific binding logic used for
attempting disjunction choices and type variable bindings under
a single interface. This makes it easier to unify top-level logic
responsible for binding enumeration.
It should also make it possible to introduce unified binding producer
interface in the future.
Encapsulate most of the logic related to new binding generation
and iteration into `TypeVarBindingGenerator`. `tryTypeVariableBindings`
is only responsible for attempting bindings and recording results.
One more step towards iterative solver.
* Move logic to ensure that r-value type var would get r-value type to `PotentialBindings`;
* Strip uncessary parens directly when creating `PotentialBinding`;
* Check if the binding is viable before inclusion in the set, instead of filtering it later;
* Assert that bindings don't have types with errors included in the set.
These are temporary.
FunctionInput is conditional on fixing some ranking behavior to not
depend on type variables having argument tuples bound to them.
Hopefully we can replace TVO_PreferSubtypeBinding with a better
mechanism that compares overload types instead.
FunctionResult is used in CSDiag's contextual type diagnostics.
This is also on the chopping block.
Since it's possible to find the same constraint through two different
but equivalent type variables, let's use a set to store constraints
instead of a vector to avoid processing the same constraint multiple
times.
A change was made to attempt to use constraints that we have between
type variables to inform potential bindings, such that if we have:
$T1 <: $T2
we would use $T1's bindings to add to the bindings of $T2. This is
only valid if we're adding bindings where $T1 is the supertype,
though, otherwise we could have the constraints:
$T1 <: $T2
$T1 <: X
imply that $T2 is a supertype of X, which doesn't make sense.
Fixes rdar://problem/40810000 (aka https://bugs.swift.org/browse/SR-7875).
Before checking any requirements of the binding type, let's look
through @autoclosure and/or non-variable types if source constraint
requires that, otherwise we'd end up creating bindings for types
which later on might end up causing infinite recursion like dependent
member types in result position of @autoclosure parameter.
Resolves: rdar://problem/38272904
Don't attempt to store literal bindings directly to `PotentialBindings`
since they might get superseded by non-literal bindings deduced from
other constraints, also don't attempt to check literal protocol conformance
on type variables or member types since such types would always end-up
returning trivial conformance which results in removal of viable literal types.
Resolves: rdar://problem/38535743
Allow certain bindings and conversions involving non-escaping
function types to succeed in "diagnostic" mode to gather fixes
and diagnose such problems better, expecially related to
conversions to 'Any' and generic parameters.
Resolves: rdar://problem/38648760
Port multiple test-cases from `test/Constraints/closures.swift`
to SILGen to verify that closures are inferred as having `Void`
result type, and there is no function conversion thunk emitted
to convert from `() -> T` to `() -> Void` for literal closures.
If we could find a binding for type variable representing closure result
let's also add implicit `Void` type as another pontential binding to attempt
because there is an implicit conversion from `() -> T` to `() -> Void`
so finding `Void` early is going to help avoid function conversions down
the line.
Resolves: rdar://problem/37790062
Move all the code specific to dealing with relational constraints out
into a separate function.
I expect to do more refactoring here so this is likely not the final
form for this code - just one step in the direction of breaking things
down into smaller logical pieces.
Attempt to use potential bindings inferred for related types variables
discoverable through 'subtype' constraints, this helps to build a
more precise bindings domain for each type variable.
Resolves: rdar://problem/38159133
Improve support for Optional among other things.
Return Any when it is really the best answer given the types involved,
or nullptr if we cannot yet produce an accurate result.
This implementation returns Any? when joining Any with an
Optional<T>. In our type system both Any and Any? are effectively
subtypes of one another since each can hold all the values that the
other can hold. So this choice is somewhat arbitrary, but does line up
nicely with the notion that T is always a subtype of T?.
Fixes a bug in `getPotentialBindings` when the source of the bindings
is 'OptionalObject' constraint and type variable is on the left-hand
side of that constraint, that makes such type variable always have an
optional type since right-hand side of 'OptionalObject' is its 'object'
type.
Resolves: rdar://problem/37508855
When bindings are picked for particular type variable, right-hand
side of the binding might be another type variable wrapped into optional
type, when trying to determine if both sides of the binding have the
same l-valueness it's imperative to look throught optional type of the
right-hand side. Otherwise new binding might be effectively unsolvable.
Resolves: rdar://problem/37291371
Instead of binding collection types directly let's try to
bind using temporary type variables substituted for element
types, that's going to ensure that subtype relationship is
always preserved.
Resolves: rdar://problem/35541153
