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.
The `Stmt` and `Expr` classes had both `dump` and `print` methods that behaved similarly, making it unclear what each method was for. Following a conversation in https://forums.swift.org/t/unifying-printing-logic-in-astdumper/15995/6 the `dump` methods will be used to print the S-Expression-like ASTs, and the `print` methods will be used to print the more textual ASTPrinter-based representations. The `Stmt` and `Expr` classes seem to be where this distinction was more ambiguous. These changes should fix that ambiguity.
A few other classes also have `print` methods used to print straightforward representations that are neither the S-Expressions nor ASTPrinters. These were left as they are, as they don't cause the same ambiguity.
It should be noted that the ASTPrinter implementations themselves haven't yet been finished and aren't a part of these changes.
In cases where we have multiple designated types, sort the types that
were designated for this operator based on any information we can
gather about actual argument types at usage sites.
We can consider extending this further in a future commit to ignore
designated types when we have concrete type information that we are
confident of.
This counts the number of leaf scopes we reach while solving the
constraint sytem, and is a much better measure of the growth of
unnecessary work than the total number of scopes opened.
There were two tests where I had a difficult time getting scale-test
to fit the curve even after adjusting some of the parameters, so I've
left those to use the old stat for now.
Have the constraint solver consider multiple designated types for an
operator. We currently consider the overloads from each in turn,
stopping as soon as we have a solution. As a result, we can still end
up with exponential type checking in some cases if an operator has
more than a single designated type. This still allows us to reduce the
base of that exponent, though, which makes it possible to increase the
number of expressions we can type check successfully in practice.
Currently (with or w/o failures) constraint system is not returned
back to its original state after solving, because constraints from
initial "active" list are not returned to the system. To fix that
let's allocate "initial" scope which captures state right before
solving begins, and add "active" list to the solver state to capture
information about "active" constraints at the time of its creation.
This is follow-up to https://github.com/apple/swift/pull/19873
Add parsing, type checking, serialization, and deserialization support
for specifying multiple types as "designated" for operator lookup for
a given operator declaration.
The constraint solver still considers only the first type when
deciding the order to attempt the elements of a disjunction, so this
doesn't really change behavior yet.
