* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
This reverts commit 2f80af15ec.
I expected this to have no effect, but it results in one of the
expression type checker tests taking longer, so that test was disabled.
This commit also re-enables the test since it now passes again.
Recent changes have made these tests borderline slow, which means they
no longer fail.
Let's make them really slow instead!
(...since they do not scale well, and we cut the actual testing time off at
1s in the solver, which means really slow isn't going to affect test
time much).
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
There are situations where we know equivalence relationship between
multiple disjunctions, let's prune dependent choice space based on
choice picked for the parent disjunction.
Resolves: rdar://problem/35540159
Remove function-to-function type match score increase, which should only
happen contextually in presence of other restrictions, this used to fix
the case related to matching of arrays of functions with and w/e `throws`
as function parameters which used to be ambigious, and now handled by
collection-upcast conversion score.
Resolves: rdar://problem/35142121
Per SE-0054, implicitly unwrapped optional is not a distinct type in the
type system, but rather just the notion that certain Optionals (denoted
by the sigil "!" rather than "?") can be implicitly unwrapped.
This is a first step in the direction of implementing this notion by
emitting a warning if the type is spelled out.
Currently edge related to the parameter bindings is contracted
without properly checking if newly created equivalence class has
the same inout & l-value requirements. This patch improves the
situation by disallowing contraction of the edges related to parameter
binding constraint where left-hand side has `inout` attribute set.
Such guarantees that parameter can get `inout` type assigned when
argument gets `l-value` type.
Resolves: rdar://problem/33429010
Change the potential binding ranking logic to prefer type variables
which don't have other type variables related to them, but have literal
bindings, over the ones that do have other type variables.
Presently subtype constraint is considered a candidate for contraction
via `shouldContractEdge` when left-hand side of the subtype constraint
is an inout type with type variable inside. Although it's intended to
be used only in combination with BindParam constraint assigned to the
same variable, that is actually never checked and contraction of subtype
constraint like that is invalid.
Resolves: rdar://problem/34333874
We've found in practice that multiple different types of expressions
are still going to benefit from shrinking continuing even when it
couldn't simplify up to 10 sub-expressions.
Also tweak some of the test iteration bounds to ensure we have data
that better fits the models.
Ideally our counter would be a bit better so that those kinds of
tweaks wouldn't be necessary.
This failed once locally because it was relatively close to 1s for type
checking time, so make it a bit more complex so that it is almost
certain to fail with the current compiler compiled with
release/no-asserts.
Move disjunction selection logic one level up from the `solveSimplified`
which allows to simplify its logic and avoid collecting disjunctions
multiple times for each solver step.
Sort constraint components/buckets based on how many disjunctions
they have, that helps to prune some of the branches with incorrect
solutions early which limits overall depth of the search.
Resolves: SR-4714
Add type checker performance tests under
validation-test/Sema/type_checker_perf.
Under ./fast/ we have tests that compile reasonably quickly now but at
one point did not.
Under ./slow/ we have tests that are still very slow to compile.
Some tests use %scale-test and others
-solver-expression-time-threshold to determine if they are scaling
well or compiling fast enough.
I've got several more tests gathered that have not yet been set up to
run in our test system. Those are forthcoming!
Further contributions welcome.
Thanks go to @xedin who helped collect most of the test cases.
Special DeclNames represent names that do not have an identifier in the
surface language. This implies serializing the information about whether
a name is special together with its identifier (if it is not special)
in both the module file and the swift lookup table.
There are possible situations when we find solutions with String
and String -> UnsafePointer conversions at the same time for
expressions with default string literals. In order to disambiguite
such situations let's prefer solutions without String -> UnsafePointer
conversions if possible.
Restrict skipping of the generic overloads only to the situations
when non-generic solution doesn't have any restrictions/fixes, because
there is a possibility that generic overload could produce a better
solution.
Resolves: rdar://problem/32204609.
This reverts commit
ecfa406fc5, which was reinstating
3c5b393e0c.
It does not revert one test change from that commit, because
inexplicably one of the tests is still failing, probably due to some
other changes that have happened since. I'm leaving a ticket open to
investigate.
I've added one of the new cases that is failing as a result of this
change.
This is being reverted not because of bugs in this particular commit,
but because it seems to be exposing other bugs in the type checker that
are resulting in source compatibility problems. We need to shake these
other bugs out of the type checker before bringing this change back.
We previously used a simple heuristic of visiting the disjunction with
the fewest number of elements in it.
Instead, this commit introduces a new way to select the best disjunction
to explore based on attempting disjunctions based on either how much
information we have about the associated type variables (e.g. how many
of the arguments of a function call in the case of bind overload
disjunctions) or by other criteria that help constraint the search or
split the connected components (e.g. coercions and calls to
initializers).
A key part of the improvement here is allowing the type checker to
attempt bindings of types to type variables when there are still
argument conversion constraints between type variables in the
system. The insight here is if there are no other constraints blocking
an attempt to bind types and we have types to try, we will be able to
test those types against active conformance constraints and potentially
fail much earlier while solving.
Visiting disjunctions in a different order exposed some other problems
with the type checker including a couple cases where map is used that
are now considered ambiguous due to problems in how we are ranking
solutions.
I measured an 11-13% reduction in type checking time for the standard
library using a release build of the compiler.
