For operators with default implementations in an extension, we don't
want to typecheck it both with overloads from the protocol type and
the ones from the extension.
These are cases that I know are faster when this is enabled. The test
updates all additionally disable the existing performance hacks as
well as the shrink phase of the solver.
This will minimize the chance of breaking code. Currently SwiftLint
has one "too complex" expression with this change. Further changes to
the solver may improve that situation, and potentially allow us to
move this out from -swift-version 5 if we're willing to take the risk
of breaking some code as a result.
Attempt to visit disjunctions that are associated with applies where
we have at least some useful information about the types of all of the
arguments before visiting other disjunctions.
Two tests here got faster, and one slightly slower. One of the
faster tests is actually moving from test/ to the slow/ directory in
validation-test because despite going from 16s to less than 1s, it was
still borderline for what we consider the slow threshold, so I made
the test more complex. The one that got a little slower is
rdar22022980, which I also made more complex so that it is clearly
"slow" by the way we are testing it.
slower:
rdar22022980.swift
faster:
rdar33688063.swift
expression_too_complex_4.swift
* Move logic to ensure that r-value type var would get r-value type to `PotentialBindings`;
* Strip uncessary parens directly when creating `PotentialBinding`;
* Check if the binding is viable before inclusion in the set, instead of filtering it later;
* Assert that bindings don't have types with errors included in the set.
* Obsolete ModifierSlice typealiases in 5.0
* Obsolete *Indexable in 5.0
* Obsolete IteratorOverOne/EmptyIterator in 5.0
* Obsolete lazy typealiases in 5.0
* Drop .characters from tests
* Obsolete old literal protocols in 5.0
* Obsolete Range conversion helpers in 5.0
* Obsolete IndexDistance helpers in 5.0
* Obsolete Unsafe compat helpers in 5.0
* Obsolete flatMap compatibility helper in 5.0
* Obsolete withMutableCharacters in 5.0
* Obsolete customPlaygroundQuickLook in 5.0
* Deprecate Zip2Sequence streams in 5.0
* Replace * with swift on lotsa stuff
* Back off obsoleting playground conformances for now
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
One expression in the new hashing implementation is going exponential,
accounting for a huge amount of type-checking type. Add (admittedly ugly)
“as UInt64” annotations to greatly reduce the time to type-check this
expression.
*Ahem* type-checking time for the standard library goes from 24s->14s with
this change. Added a type-checker “slow” performance test and captured
the problem in rdar://problem/42672946.
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.
This is how we originally controlled whether or not we printed out ownership
annotations when we printed SIL. Since then, I have changed (a few months ago I
believe) the ownership model eliminator to know how to eliminate these
annotations from the SIL itself. So this hack can be removed.
As an additional benefit, this will let me rename -enable-sil-ownership to
-enable-sil-ownership-verifier. This will I hope eliminate confusion around this
option in the short term while I am preparing to work on semantic sil again.
rdar://42509812
SE-0213 improved cases like that but we still have problem with operator
overloads, so just need to make this a bit more complicated to reproduce again.
Resolves: rdar://problem/42304000
...unless the argument is an `Any?`, in which case we prefer `f(_: Any?)`.
This change also results in our selecting f<T>(_: T) over f(_:
Any). Coercing with 'as Any' makes it possible to explicitly select
the Any overload. Previously there was no way to select the generic
overload.
Implementation is as follows: In `preCheckExpression` try to
detect if there is `T(literal)` call in the AST, replace it with
implicit `literal as T`, while trying to form type-checked AST,
after constraint solving, restore source information and drop
unnecessary coercion expression.
Resolves: rdar://problem/17088188
Resolves: rdar://problem/39120081
Resolves: rdar://problem/23672697
Resolves: rdar://problem/40379985
From the perspective of the compiler implementation, they're elements. But users will think of these as cases—and many diagnostics already refer to these as enum cases.
None of these failed naturally based on the limits of the "too
complex" heuristic and several were relatively closer to the time-out
threshold used in the test RUN line.
Increasing the complexity will ensure that we don't see spurious
failures on builders or on local machines.
This was originally commited in
3d32e89e33, and then backed out in
c40fd3966c due to concern over
behavioral changes.
This version avoids the optimization when there are any optional types
involved in the signatures of the functions.
For these cases, compareDeclarations can return the wrong order at the
moment.
I have another PR in the works that attempts to begin unraveling some
of the issues around fixing the overload comparisons.
I think there is something far more narrow we could do here, but I'm
not sure if there is real code that such a hack would benefit from. We
can leave that to consider another day.
Fixes rdar://problem/40819547 (aka https://bugs.swift.org/browse/SR-7884).
When selecting the next disjunction to attempt, try to find one that
is a disjunction of bindings where the type being bound is the
converted-to type in a conversion constraint. Attempting these early
makes it possible to split constraint systems, eliminating exponential
behavior.
Fixes: rdar://problem/40344044
Usually this happens directly, through some use of the class and its
conformance. However, if a conformance is /only/ used to satisfy an
associated type, we seem to bypass the step that actually infers
selector names for accessors, even though we do it successfully for
methods. Fix this by making sure the accessor decls are validated when
a property is, something that normal uses of a property probably have
to do anyway.
Also, simplify inferObjCName by assuming/asserting that it is only
used on things that are already marked @objc.
https://bugs.swift.org/browse/SR-6944
Don't attempt to store literal bindings directly to `PotentialBindings`
since they might get superseded by non-literal bindings deduced from
other constraints, also don't attempt to check literal protocol conformance
on type variables or member types since such types would always end-up
returning trivial conformance which results in removal of viable literal types.
Resolves: rdar://problem/38535743
This fixes two easy cases where we would go exponential in type
checking tuple literals.
Instead of generating a conversion to a single type variable (which
results in one large constraint system), we generate a conversion ot
the same type that appears in the initializer expression (which for
tuples is a tuple type, which naturally splits the constraint system).
I experimented with trying to generalize this further, but ran into
problems getting it working, so for now this will have to do.
Fixes rdar://problem/20233198.
