When we perform constraint generation while solving, capture the
type mappings we generate as part of the solver scope and solutions,
rolling them back and replaying them as necessary. Otherwise, we’ll
end up with uses of stale type variables, expression/parameter/type-loc
types set twice, etc.
Fixes rdar://problem/50390449 and rdar://problem/50150314.
When calling a function whose parameter specifies a function builder
with a multi-statement closure argument, transform the closure into
a single expression via the function builder. Should the result
type checker, replace the closure body with the single expression.
Add `llvm_unreachable` to mark covered switches which MSVC does not
analyze correctly and believes that there exists a path through the
function without a return value.
Introduce an attribute @_disfavoredOverload that can be used to state
that a particular declaration should be avoided if there is a
successful type-check for a non-@_disfavoredOverload. It's a way to
nudge overload resolution away from particular solutions.
The ConstraintSystem class is on the order of 1000s of bytes in size on
the stacka nd is causing issues with dispatch's 64k stack limit.
This changes most Small data types which store data on the stack to non
small heap based data types.
Previously, an OpaqueUnderlyingType constraint was created only if the
contextual type purpose was CTP_ReturnStmt. Now that there is a
distinct CTP for implicit, single-expression returns, an
OpaqueUnderlyingType constraint needs to be created if that is the CTP.
When type-checking a return statement's result, pass a new
ContextualTypePurpose when that return statement appears in a function
with a single expression. When solving the corresponding constraint
system, the conversion constraint will have a new ConstraintKind. When
matching types, check whether the constraint kind is this new kind,
meaning that the constraint is between a function's single expression
and the function's result. If it is, allow a conversion from
an uninhabited type (the expression's type) to anything (the function's
result type) by adding an uninhabited upcast restriction to the vector
of conversions. Finally, at coercion time, upon encountering this
restriction, call coerceUninhabited, replacing the original expression
with an UninhabitedUpcastExpr. Finally, at SILGen time, treat this
UninhabitedUpcastExpr as a ForcedCheckedCastExpr.
Eliminates the bare ConstraintSystem usage from
typeCheckFunctionBodyUntil, ensuring that the same code path is followed
for all function bodies.
We have a systemic class of issues where noescape types end up bound to
type variables in places that should not. The existing diagnostic for
this is ad-hoc and duplicated in several places but it doesn't actually
address the root cause of the problem.
For now, I've changed all call sites of createTypeVariable() to set the
new flag. I plan on removing enough occurrences of the flag to replicate
the old diagnostics. Then we can continue to refine this over time.
Since filtering currently runs as part of the `applicable function`
constraint processing, "keypath dynamic member lookup" choice can't
be attempted in-place because that would also try to operate on that
constraint, so instead let's keep the disjunction, but disable all
unviable choices.
Resolves: rdar://problem/49533404
Implicit argument expression was necessary to generate keypath
constraint which is used to validate a choice picked for the member.
But since read-only check has been factored out it's now possible
to validate choice directly in combination with new 'keypath dynamic lookup'
locator associated with member type variable which represents result
of the dynamic lookup.
This draws a distinction between disabled choices with and without
fixes - former is disabled because it's unrelated, latter because
it only makes sense to attempt it during "salvage" mode while trying
to produce diagnostics.
When we’re trying to find the overload set corresponding to a particular
type variable, look through “optional object of” constraints that represent
the use of ? binding or ! forcing. This allows us to find overload sets
when referring to, e.g., @objc optional protocol requirements.
This narrow favoring rule makes more sense as part of disjunction
partitioning, because it is not dependent on the use site at all and
should only kick in when other options fail.
The disjunction partitioning logic was only used for the experimental
designated-types feature, but is generally useful. Unify the code
paths so we always do the partitioning, with only the designated-types
part being enabled/disabled by the flag.
When simplifying a function application constraint, check the argument
labels for that application against the disjunction containing the overload
set, disabling any overloads with mis-matching labels. This is staging for
several different directions:
* Eliminating the argument label matching from performMemberLookup, where it
does not belong
* More aggressively filtering the overload set when we have some concrete
information about argument types
* Identifying favored constraints when we have some concrete information
about argument types
At present, the only easily-visible effect of this change is that
we now properly handle argument label matching for non-member functions.
Constraint generation for function application expressions contains a simple
hack to try to find the common result type for an overload set containing
callable things. Instead, perform this “common result type” computation
when simplifying an applicable function constraint, so it is more
widely applicable.
`selectApplyDisjunction` only makes sense in conjunction with
designated types feature because it's going to prioritize disjunctions
with arguments which are known to conform to literal protocols.
Prioritization like that is harmful without designated types feature
because it doesn't always lead to better constraint system splits,
and could prioritize bigger disjunctions which harms chances to
short-circuit solving.
Resolves: rdar://problem/47492691
Instead of storing information about expression depths in the
solver state (which gets recomputed for salvage) let's track
it directly in constraint system, which also gives solver
access to it when needed e.g. for fixes.
After collecting possible conformances and types for each argument,
`ArgumentInfoCollector` attempts literal protocol minimalization
to reduce the set of possible types argument could assume. Let's
exclude literal protocols without default types like
`ExpressibleByNilLiteral` from consideration by that algorithm.
Resolves: rdar://problem/47266563
If lookup couldn't find anything matching given name, let's try to
fake its presence based on how member is being used. This is going
to help (potentially) type-check whole expression and diagnose the
problem precisely.
Sometimes constraint solver fails without producing any diagnostics,
it could happen during different phases e.g. pre-check, constraint
generation, or even while attempting to apply solution. Such behavior
leads to crashes down the line in AST Verifier or SILGen which are
hard to diagnose.
Let's guard against that by tracking if solver produced any diagnostics
upon its failure and if no errors were or are scheduled to be produced,
let's produce a fallback fatal error pointing at affected expression.
Resolves: rdar://problem/38885760
For operators with multiple designated types, we attempt to decide the
best order for exploring the types. We were doing this by checking
for matching types. Extend this to also consider conforming types.
Fixes: rdar://problem/46687985
In 119864a0f5 I moved the consideration
of top-level operators sooner when the designated types feature is
enabled, and that fixed some source compatibility issues that show up
in our test suite, but also introduced a new one.
For maximum source compatibility we'll just split the partitions up
into the operators from designated types, followed by operators that
are not deprecated or disabled, followed by the deprecated ones, and
finally the disabled ones.
When -Xfrontend -solver-enable-operator-designated-types is enabled,
attempt operators defined outside of types before attempting operators
defined within (non-designated) types.
This helps fix some source compatability problems that arise from
attempting some of the operators defined for Optional (e.g. we
would sometimes typecheck successfully with the operator for Optional
and then inject values into Optionals and skip attempting
globally defined operators that also match).
The old behavior resulted in failures in SourceKit and SIL Optimizer
tests when enabling designated types by default in our test suite.
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
We try to work more-or-less bottom up in the expression when we
attempt apply disjunctions first. This is very helpful to get good
results with designated types enabled in the solver. Rather than
forcing tests to specify both `-swift-version 5` (which also enables
this bottom-up behavior) and enabling designated types, allow them to
just enable the later to get the behavior.
We'll eventually have to revisit this when we decide the specific
conditions that we'll enable the use of designated types under.
Also add overloads for these operators to an extension of Array.
This allows us to typecheck array concatenation quickly with
designated type support enabled and the remaining type checker hacks
disabled.
* 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.
