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.
Rather than looking directly at the subexpressions of a function
application to determine whether they are literal expressions, look
instead at the type variables for the argument types: if they have a
literal-conforms-to constraint on them, use the named literal protocol
to determine favored declarations.
This refactoring is intended to broaden the applicability of the
existing "favored declaration" machinery to also consider the literal
constraints of other type variables that are equivalent to the type
variable named by the argument.
Given an overload set, attempt to compute a "common type" that
abstracts over all entries in the overload set, providing more
structure for the constraint solver.
Since @autoclosure attribute is associated with declarations
it makes more sense to move diagnostics to where type of the
parameter has been completely resolved. This also helps to support
parameters with typealiases pointing to function types without
any extra logic in the resolver.
Solving Bind is a little easier than Equal. The only remaining uses of Equal
are in the .member syntax and keypaths; if we can refactor those, we might be
able to simplify LValue handling in the type checker in general.
We're looking at the generic signature of the extension, so it must
have been validated at this point.
I don't have a test case for this and maybe it never came up, but
nothing forces it to be validated here so let's make it more robust
by doing it explicitly.
Removes the _getBuiltinLogicValue intrinsic in favor of an open-coded
struct_extract in SIL. This removes Sema's last non-literal use of builtin
integer types and unblocks a bunch of cleanup.
This patch would be NFC, but it improves line information for conditional expression codegen.
Currently when `LazyInitializerExpr` is added to the AST it's not
given an explicit type. Because of that constraint solver silently
fails in contraint generator without diagnostic. But since
sub-expression associated with `LazyInitializerExpr` is already
type-checked it makes sense to set its type explicitly.
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
In postfix completion, for operator completion, we do:
1. Type check the operand without applying it, but set the resolved
type to the root of the expression.
2. For each possible operators:
i. Build temporary binary/postfix expression
ii. Perform type checking to see whether the operator is applicable
This could be very slow especially if the operand is complex.
* Introduce `ReusePrecheckedType` option to constraint system. With
this option, CSGen respects pre-stored types in expressions and doesn't
take its sub-expressions into account.
* Improve type checking performance because type variables aren't
generated for sub-expressions of LHS (45511835)
* Guarantee that the operand is not modified by the type checker because
expression walkers in `CSGen` doesn't walk into the operand.
* Introduce `TypeChecker::findLHS()` to find LHS for a infix operator from
pre-folded expression. We used to `foldSequence()` temporary
`SequenceExpr` and find 'CodeCompletionExpr' for each attempt.
* No need to flatten folded expression after initial type-checking.
* Save memory of temporary `BinaryExpr` which used to be allocated by
`foldSequence()`.
* Improve accuracy of the completion. `foldSequence()` recovers invalid
combination of operators by `left` associative manner (with
diagnostics). This used to cause false-positive results. For instance,
`a == b <HERE>` used to suggest `==` operator. `findLHS()` returns
`nullptr` for such invalid combination.
rdar://problem/45511835
https://bugs.swift.org/browse/SR-9061
In #7530, NominalTypeDecl::lookupDirect() started returning TinyPtrVector instead of ArrayRef so that it wouldn’t be returning a pointer into a mutable data structure. Unfortunately, some callees assigned its return value into an ArrayRef; C++ happily converted the TinyPtrVector to an ArrayRef and then treated the TinyPtrVector as out-of-scope, so the ArrayRef would now point to an out-of-scope object. Oops.
If the sub-expression of the 'try?' is optional, the result will be the same level of optional-ness.
If the sub-expression is non-optional, the result is optional.
Thus, the following lines all end up with the same type of 'Int?'
- let x = try? 3 as Int
- let x = try? 3 as? Int
- let x = try? 3 as Int?
It is possible for the SIL optimizers, IRGen, etc. to request information
from the AST that only the type checker can provide, but the type checker
is typically torn down after the “type checking” phase. This can lead to
various crashes late in the compilation cycle.
Keep the type checker instance around as long as the ASTContext is alive
or until someone asks for it to be destroyed.
Fixes SR-285 / rdar://problem/23677338.
It was useful when logic related to `BridgingConstraint` was part of
`Conversion` constraint, which could be generated as a result of implicit
conversion for an operator parameter.
`\.self` is the final chosen syntax. Implement support for this syntax, and remove the stopgap builtin and `WritableKeyPath._identity` property that were in place before.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
We previously allowed these closures to default to (), but be inferred
as other types as well, which means that we will find some expressions
to be ambiguous because we end up finding multiple viable solutions
where there is really only one reasonable solution.
Fixes: rdar://problem/42337247
Now that function types cannot have a naked type variable as
their input type it's no longer possible to have an unsolved
ArgumentTupleConversion constraint, so we can bypass most of
the logic in matchTypes() and call matchCallArguments() instead.
Previously we would generate the following constraint here, where
'index' and 'output' are concrete types and $input is a type
variable:
- ValueMember(base, $input -> output)
- ArgumentTupleConversion(index, $input)
The problem is that we built a function type where the entire input
was a type variable, which would then bind to an argument list.
We could instead generate this constraint:
- ValueMember(base, $member)
- ApplicableFunction(index -> output, $member)
I also had to redo how keypaths map locators back to key path
components. Previously the ArgumentTupleConversion was created
with a locator ending in KeyPathComponent.
Now the ApplicableFunction is created with this locator, which means
the argument match is performed with a locator ending in
ApplyArgument.
A consequence of this is that the SubscriptIndex and SubscriptResult
locator path elements are no longer used, so remove them.
This requires various mechanical changes in places we look at
locators to handle this change. Should be NFC.
Previously we would generate the following constraint here, where
'base' was a concrete type and $arg and $result are type variables:
- ValueMember(base, $arg -> $result)
The problem is that we built a function type where the entire input
was a type variable, which would then bind to an argument list.
We could instead generate this constraint:
- ValueMember(base, $method)
That is not NFC though because we no longer have a type variable
bound to the argument list. Since $arg was created with
TVO_PreferSubtypeBinding, we would rank solutions by comparing
argument lists.
So we use the new FunctionInput constraint to extract the input
type of $method:
- ValueMember(base, $method)
- FunctionInput($method, $arg)
Once the ValueMember constraint is solved and $method has a fixed
type, $arg is bound to the function type's argument list, and
since it was created with TVO_PreferSubtypeBinding it participates
in ranking as before.
Amusingly enough, none of the tests in our suite exercised this
behavior, but the standard library would fail to build. So add a test.
These usages of getOld() always pass in a ParenType or TupleType
as the input type, so there's no conceptual difficulty with
using the new representation instead.
Note that eventually we want to remove decomposeInput() too.
However until ApplyExpr and friends are redesigned to directly
hold multiple arguments instead of a single argument
sub-expression that is a ParenExpr or TupleExpr, we don't
have a good way to avoid building a tuple type and decomposing
it in this one case.
Instead just inline what getOld() does so we can move forward.
I needed this for materializeForSet remission, but it makes inherited
variadic initializers work, too.
I tried to make this a reasonable starting point for a real language
feature. Here's what's still missing:
- syntax
- semantic restrictions to ensure that the expression isn't written in
invalid places or arbitrarily converted
- SILGen support for expansions that aren't the only variadic argument
rdar://16331406
