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
Replace the GenericTypeResolver type hierarchy with TypeResolution,
which more simply encapsulates the information needed to resolve
dependent types and makes explicit those places where we are
using resolution to contextual types.
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
TypeResolutionFlags is overly complicated at the moment because the vast
majority of flag combinations are impossible and nonsensical. With this
patch, we create a new TypeResolverContext type that is a classic enum
and far easier to reason about. It also enables "exhaustive enum"
checking, unlike the "flags" based approach.
Existence of semantic expr (`getSemanticExpr()`) prevents ASTWalker
walking into the *original* sub expressions which may cause
re-typechecking failure. For example,
`ConstraintGenerator::visitArrayExpr()` assumes we already visited its
elements, but that's not the case if the semantic expr exists.
rdar://problem/42639255
Using dummy UnresolvedMemberExpr doesn't give us much benefit. Instead, use
CodeCompletionExpr which is type checked as type variable so can use
CodeCompletionTypeContextAnalyzer to infer context types.
This way, we can eliminate most of special logic for UnresolvedMember.
rdar://problem/39098974
