Introducing the SIMD operators back into the standard library regresses
one test (SR-139 goes exponential against without the designated types
for operatores feature). Split that part of the test out.
Implements SE-0229.
Also updates simd module types in the Apple SDKs to use the new types, and updates a couple tests to work with the new types and protocols.
The current implementation isn't really useful in the face of generic
overloads. It has never been enabled by default, and isn't useful to
keep around if it is disabled. If we ever want to bring it back,
we know where to look!
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 additional checking for complexity of the shrinking candidate
given the number of the expressions solved so far and total number
of disjunctions present. This allows us to bail quicker in complex
expression cases which, at the very least, produces an error instead
of being "stuck" in solver for a long time.
Resolves: rdar://problem/32034560
I've opened https://bugs.swift.org/browse/SR-4714 to track fixing the
slowness here and/or moving the test into the validation suite.
We're currently not "too complex" here given the current metric, but we
are still extremely slow, adding several minutes to test runs.
One expression in this test becomes ambiguous when the shrink() pass is
disabled. Enabling the constraint propagation pass disables the shrink
pass.
For now we'll run this with -propagate-constraints explicitly enabled
and with the expected output changed. This is a regression that will
need to be investigated and fixed in the solver.
In ConstraintGenerator::visitDictionaryExpr(), if the dictionary_expr has a
contextual type which is also a dictionary type, use it to add a new type
constraint for each of the dictionary_expr's elements. This has a huge effect
on solver performance for dictionary literals with elements that have
overloading. The approach closely follows that used in
ConstraintGenerator::visitArrayExpr(), which has included a similar
optimization (from git commit a22b391) for over two and a half years.
I've also added a couple of new test cases which would trigger the bug without
this fix.
ExprCollector is extended to cover all generic collections instead of
only dictionary expressions. Contextual type propagation is extended
to support partial solving of collections embedded into coerce expressions.
This reverts commit f590a1ba03.
It breaks this kind of code:
test.swift:2:34: error: cannot convert value of type 'Int' to expected element type 'UInt32'
let lengthBytes: [UInt32] = [55 * 8, 0]
~~~^~~
UInt32( )
ExprCollector is extended to cover all generic collections instead of
only dictionary expressions. Contextual type propagation is extended
to support partial solving of collections embedded into coerce expressions.
Instead of failing shrinking when there are no solutions for current
sub-expression, let's restore overload domains for previously solved
sub-expressions and move on trying to solve next expression in the queue.
DPC algorithm tries to solve individual sub-expressions and combine
resolved types as a way to reduce pre-existing OSR domains. Solving
is done bottom-up so each consecutive sub-expression tightens
possible solution domain even further.
DPC algoritm tries to solve individual sub-expressions and combine
resolved types as a way to reduce pre-existing OSR domains. Solving
is done bottom-up so each consecutive sub-expression tightens
possible solution domain even further.
