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
* 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.
