`ConstraintSystem::finalize` copies several maps from the constraint
system into the fresh `Solution`: `overloadChoices`,
`argumentMatchingChoices`, `nodeTypes`, `keyPathComponentTypes`, etc.
All are populated by single-element inserts that grow the destination
DenseMap incrementally, producing a cascade of rehashes. Pre-size the
destination maps to their source's size before inserting. The loops are
otherwise unchanged.
Measured on a synthetic stress test (N-element `[UV(u: Float(bitPattern:
0xX), v: Float(bitPattern: 0xY)), ...]`, 2-run averages, baseline vs
patched):
| N | baseline | patched | speedup |
|-----:|---------:|--------:|--------:|
| 1000 | 1.06s | 0.72s | 1.47× |
| 2000 | 5.82s | 3.06s | 1.90× |
| 4000 | 22.89s | 15.41s | 1.49× |
Memory impact is negligible (same final map sizes; we just avoid
intermediate doublings). This is a pure CPU win from a
behavior-preserving change. This doesn't solve the O(N²) memory problem,
just makes smaller cases faster.
The previous logic was relying on doing `coerceCallArguments` with the
full argument list instead of only the non-trailing args, and wasn't
handling the non-shorthand-init case. Update the logic to fix-up the
apply during the pre-walk, ensuring it gets applied consistently.
rdar://170076966
Use the trailed recordPotentialThrowSite helper when replaying solution state so replayed potential throw sites are rolled back with solver scopes.
Co-authored-by: Codex <noreply@openai.com>
Typed throws adoption could cause source compatibility regressions
because it makes some overloads generic when they used to be concrete
and didn't participate in this generic-only optimization that covers
cases where there are only two overloads.
Resolves: rdar://171016238
We already had bookkeeping to track which statement in a multi-statement
closure we were looking at, but this was only used for the 'reasonable time'
diagnostic in the case that we hit the expression timer, which was almost
never hit, and is now off by default. The scope, memory, and trial limits
couldn't use this information, so they would always diagnose the entire
target being type checked.
Move it up from ExpressionTimer to ConstraintSystem, so that we get the
right source location there too. Also, factor out some code duplication
in BuilderTransform to ensure we get the same benefit for result builders
applied to function bodies too.
Add the application constraint before the member constraint, which
allows us to get rid of the special-cased delaying logic for dynamic
member subscripts. The diagnostic change here is due to the fact that
we no longer have a simplified type for the result in CSGen, which
would also be the case if we had a disjunction for the member.
Since such choices are all but guaranteed to be worst than any
other non-disfavored choice, let's attempt them last to avoid
having to form a complete solution just to filter it out during
ranking.
Don't attempt this optimization if call has number literals.
This is intended to narrowly fix situations like:
```swift
func test<T: FloatingPoint>(_: T) { ... }
func test<T: Numeric>(_: T) { ... }
test(42)
```
The call should use `<T: Numeric>` overload even though the
`<T: FloatingPoint>` is a more specialized version because
selecting `<T: Numeric>` doesn't introduce non-default literal
types.
(cherry picked from commit 8d5cb112ef)
This is currently unused because current mechanism set favored choices
directly but it would be utilized by the disjunction optimizer.
(cherry picked from commit e404ed722a)
Package the flag into `performanceHacksEnabled()` method on
`ConstraintSystem` and start using it to wrap all of the hacks
in constraint generator and the solver.
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
We iterate over the DenseMap and simplify both types appearing
in the key. If multiple keys simplify to the same type, later
keys overwrite earlier keys, so the outcome depends on hash
table order.
Fix this by introducing an arbitrary tie break: we prefer the
highest-numbered restriction.
Fixes rdar://146780049.
The two GatherKinds no longer share any implementation, so there's
no point keeping the logic together. Doing this also allows removing
the acceptConstraintFn from gatherAllConstraints(), which further
simplifies depthFirstSearch().
Within the constraint system, introduce a new kind of conformance constraint,
a "nonisolated conforms-to" constraint, which can only be satisfied by
nonisolated conformances. Introduce this constraint instead of the normal
conforms-to constraint whenever the subject type is a type parameter that
has either a `Sendable` or `SendableMetatype` constraint, i.e., when the type
or its values can escape the current isolation domain.
Something changed here between the removal of shrink() and it's
re-introduction, and we now record constraints that contain
UnboundGenericType, which crashes in matchTypes().
As a narrow workaround, let's just ignore the contextual type if
contains an UnboundGenericType.
Fixes rdar://145092838.
Ben Cohen
Pavel Yaskevich
CognitiveDisson
Pavel Yaskevich
Hamish Knight
Nacho Soto
Slava Pestov
Anthony Latsis
Allan Shortlidge
eeckstein
Doug Gregor