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
* Restructure walkToExpr so we can handle nested implicit conversion
expressions. E.g
* Don't walk to children of 'CollectionUpcastConversionExpr'. Previously,
'walkIntoChildren' flag was ignored. Since this is also a
'ImplicitConversionExpr', just return 'subExpr()'.
(Fixes https://bugs.swift.org/browse/SR-8471 rdar://problem/43057058)
* Ignore OpaqueValueExpr in 'eraseOpenExistentialsOnly' mode. In this
mode, we allow waking into other implicit conversion expression
including 'MakeTemporarilyEscapableExpr'.
* Handle previously ignored expressions they are maked as
'llvm_unreachable' in 'ConstraintGenerator':
* Replace 'MakeTemporarilyEscapableExpr' with its original expression.
* Replace 'AutoClosureExpr' with its body.
This is helpful in experimenting with constraint solver changes that
might help us remove some of these unsound options. It's not ever mean
to be enabled, but if we're able to remove the things guarded by the
option we can eventually remove the option.
Literal initialization via coercion makes current incorrect logic
slightly more eager still, which leads to more chained arithmetic
operator expressions to be recognized as "symmetric" and their type
variables merged.
Although literal init via coercion does provide more type information,
let's treat it as regular initializer calls and don't record the types.
Resolves: rdar://problem/42750089
While inferring avoid associating type variables with closure
parameters, use cache instead and only set types when everything
is properly type-checked, this avoids multiple problems one of
them - leaking type variables outside of constraint system they
belong to.
This patch avoids merging type variables inside UnresolvedMemberExpr
and those outside, because they may not always be equivalent in CS.
Resolves: SR-8385.
Most of the use-cases of `gatherConstraints` require filtering
at least based on the constraint kind that caller is interested in,
so instead of returning unrelated results and asking caller to
filter separately, let's add that functionality directly to
`gatherConstraints`.
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.
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
Any produced diagnostics are suppressed anyway by a special
diagnostic engine attached to the new type-checker, so there
no point of doing any of that work.
Resolves: rdar://problem/22996887
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
We should pretty much always be reading
expression types out of the type cache in the constraint system.
We only see key path applications here on the path where we are
diagnosing a failure.
I haven't yet managed to come up with a test case that reproduces a crash
here.
Fixes: rdar://problem/41306933
We have a crash reported but do not have a test case and my attempt at
creating one was unsuccessful. It seems like the issue is that we have
an invalid decl that we attempt to access the interface type on,
though, so hopefully this fixes the issue.
I also tweaked the constraint generator to bail out when
checkObjCKeyPathExpr fails.
Potentially fixes: rdar://problem/40955755
8271c1a removed the last hacky usage of ArrayElementType,
leaving behind just the @lvalue-to-inout conversions. Rename
the locator path element to reflect this and do a bit of cleanup on the
unrelated-but-near-enough other hack RValueAdjustment.
Instead, generate the type variable in ConstraintGenerator.
However, we only want to generate it if we're type checking
from inside TypeChecker::typeCheckCompletionSequence(), so
add an isActivated() flag to CodeCompletionExpr. If it is
not set, constraint generation will simply fail on an
expression containing a CodeCompletionExpr.
Given something like `max(1, 2)` inside a type that conforms to Sequence, this
allows the compiler to consider Swift.max as well as the two methods with that
name on Sequence.
