While shrinking we have to allocate containers for the reduced domains
for some of the candidates, it's currently done using permanent arena
of the `ASTContext` allocator. This patch changes candidate solver to
use arena associated with the parent constraint system, which significantly
limits lifetime of domain containers.
When resolving protocol composition types, using the
old type checker to resolve the type manually instead
of the iterative type checker submits a recursive-but-
satisfiable request to the ITC. This way we directly
resolve through TypeCheckType and can catch the
circularity before it takes down the compiler.
We can only coerce metatypes covariantly but bridging
always requires an unrelated metatype cast. When
performing member lookup, especially unqualified member
lookup, disregard static members from bridged types entirely.
See SR-5670 and rdar://problem/33830526
For switch statements like the following
class Animal {}
class Cat : Animal {}
class Dog : Animal {}
func check(_ arry: [Animal]) {
switch arry {
case is [Cat]:
()
case let dogs as [Dog]:
()
default:
()
}
}
Collection downcasts are not implemented. SILGen support requires
refactoring SILGenPattern to emit the collection downcast, but
would be better solved by a future rewrite.
At least offer a more informative diagnostic than what was there
before.
There is exactly one place where the 'skipClosures' needs to be
honored, and that is when applying the solution.
Also, teach typeCheckClosureBody to propagate failures
outward instead of ignoring them.
`LinkedExprAnalyzer` is not always precise in collecting types of expressions,
so let's not try to impose anything upon linked operator expressions, which are
"mergable", except actually merging argument/result types together to help
constraint solver.
Resolves: rdar://problem/27700622
This also removes some dead code, where an early assert() ensures that
'strong' is never passed into the function, but then the function later
tries to handle 'strong'.
Finally, use a switch statement for future proofing.
1) Move the "both" check up and don't prematurely return because there
may be more errors.
2) Remove fix-it when both attributes exist. We simply don't know which
attribute the programmer wants to keep.
Again, no test case -- this was an old radar with a
-parse-stdlib example, and I'm just making this change
to verify that the original crash was fixed.
Recently TupleTypeElt was changed to add an inout bit. It is no
longer valid to construct tuple types whose elements have InOutType,
and instead the flag on the element must be set instead.
Update diagnoseImplicitSelfErrors() for the new convention.
Fixes the only remaining crash in the test case from <rdar://19569255>,
but the original issue were fixed long ago.
I don't have reduced test cases. The original test cases
were a series of frontend invocations in -parse-stdlib
mode.
While the original bugs seem to have been fixed, while
verifying I found a few places where we weren't checking
for null decls property in the ASTContext.
Probably not too useful to check this in, but I don't see it
causing any harm, either.
When type-checker is asked to skip applying deduced solution to expression,
it still needs to use type information for it to return correct result type.
This was initially added to avoid "expression was too complex" in a
case where we were not previously reporting it for -swift-version 3
but should have been. In retrospect this seems misguided since
although we would not like to regress on "too complex" expressions, we
really don't want to silently continue in the cases where we decide an
expression is "too complex", but where we have a solution that we
could use. It's better to fail.
While trying to diagnose problems with ternary/if statements don't
allow clauses, when type-checked separately, to have unresolved type
variables because that doesn't help to find errors.
Eg, if both Foo and Bar are generic, Foo.Bar<Int> would crash.
This was introduced when I refactored the code a bit to combine
the code path for nominal types and generic typealiases. I was
a little too eager in merging them, because in fact the
substitution-based approach doesn't work when the parent type
is an unbound generic, which can occur in the nominal type case.
Note that we skip validation of generic parameters when the
parent type is an unbound generic. This is because there may
be requirements relating the generic arguments of the parent
type with the generic arguments of the nested type, and unless
all arguments are known, we cannot check these requirements.
For example:
struct Outer<T : Collection> {
struct Inner<U : Collection> where T.Element == U.Element { }
}
When Sema opens the unbound generic type by creating new type
variables for each generic argument, it will also introduce
constraints corresponding to each generic requirement. Therefore
constraint system will eventually fail if the arguments are
wrong.
Fixes <https://bugs.swift.org/browse/SR-5600>,
<rdar://problem/33655028>.
Currently `visitAssignExpr` always attempts to use type
derived from destination as a contextual type for assignment
source type-checking, which doesn't always lead to better
results.
Resolves: SR-5081
When applying a solution containing an unbound reference to
an instance method of a class, the type of the new expression
did not match the type in the constraint system.
Usually this was papered over because CSApply is sprinkled
with coerceToType() calls, but we would crash when passing
an unbound reference to a generic function, or type(of:).
Integer and Floating literals are aware of their negation but
do not store the sign in the text of the value. Retrieve the
sign bit and properly interpolate the text of the literal value
with it to distinguish negative and positive literals.
