Impact for an unknown property access was frequently higher than other options
on ambiguous selections, by 3 to 5 points, causing fix selections that were
farther away and frequently noted to be in accurate. This commit lowers the
impact to be in a similar range to other fixes and this causes property accesses
to be selected more proprotionaly.
In the existing test suite, this changed the diagnostic only in the case of
protocol composition, which was also discovered to be a flawed binding lookup.
Tests added for the property lookup, tests updated for protocol composition
(Including correcting a likely error in a test specification)
We noticed that a project failed to build with prepared overloads enabled,
but built successfully with prepared overloads disabled.
It turns out that the code clearly should never have been accepted in the
first place, because the type checker was making an arbitrary choice between
two nominal type declarations with the same name.
Further inspection revealed this was because of a FIXME added in 2013 which
was far too broad. Tighten up the logic here to only disambiguate if at least
one of the two declarations is a type alias, and it has the same underlying
type as the other one. A choice between unrelated nominal type declarations
should always be ambiguous.
This still isn't perfect, because we might have two generic type aliases
that are referenced in both solutions with different substitution maps,
in which case we will still erroneously pick the first one. But this
is better than the old logic, at least.
Fixes rdar://165863775.
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.
The existing check is no-op because it would never produce a null for
`paramType` under the conditions in `else` branch. A better
API it use here is `conformsToKnownProtocol` just like in other cases.
Update special favoring logic for unlabeled unary calls to support
non-overloads member references in argument positions.
The original hack missed a case where a type of a member is known
in advance (i.e. a property without overloads) because there as
another hack (shrink) for that.
This helps in situations like `Double(x)` where `x` is a property
of some type that is referenced using an implicit `self.` injected
by the compiler.
Resolves: rdar://161419917
One test was miscategorized as 'fast' because of this issue, but it
would occasionally fail. It turns out it always fails once you ask
for 7 points or more, so let's fix that and move it back to 'slow'.
Fixes rdar://162597936.
This adds the -verify-ignore-unrelated flag. When -verify is used without -verify-ignore-unrelated, diagnostics emitted in buffers other than the main file and those passed with -verify-additional-file (except diagnostics emitted at <unknown>:0) will now result in an error. They were previously ignored. The old behaviour is still available as opt-in using -verify-ignore-unrelated, but by being strict by default it should make it harder to accidentally miss diagnostics.
To avoid unnecessary performance overhead, -verify-additional-file is still required to parse the expected-* directives in files other than the main file.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Move the logic from `FailureDiagnostic::resolveType` into
`Solution::simplifyType` to allow completion to use it too. While
here, also handle cases where the placeholder is from a different
member of the equivalence class to the generic parameter.
In preparation for removing UnresolvedType in favor of ErrorType,
start printing ErrorType as `_` unless we've enabled debug printing.
`<<error type>>` should never be presented to the user, instead `_`
now just consistently means "unknown type".
This type is only intended for pattern matching against `nil`
and the solver shouldn't early attempt to infer this type for
`nil` for arguments of `==` and `!=` operators it should instead
be inferred from other argument or result.
Resolves: rdar://158063151
Parameter type could be represented by an associated type which is
bound to a concrete type by an extension, `AbstractFunction::getType()`
should map it into context before returning because the construct is
that it always produces a function type.
Resolves: rdar://156955193
The current implementation of the check accounts only for the overload
choices present in the initial lookup but for some situations, like
bridged or optional base types, `performMemberLookup` uses a secondary
lookup as well, results of which are ignored.
Let's fold the check into `addChoice` instead and set the the flag there
to make sure that all of the choices are considered.
Resolves: rdar://143586718
Infix logical operators are usually not overloaded and don't
form disjunctions, but when they do, let's prefer them over
other operators when they have fewer choices because it helps
to split operator chains.
Infer result type of a subscript with Array or Dictionary base type
if argument type matches the key type exactly or it's a supported
literal type.
This helps to maintain the existing behavior without having to resort
to "favored type" computation.
When matching candidate like `[Int]` against `Array<Element>`
we need to conservatively assume that if the nominals match
the argument is a viable exact match because otherwise it's
possible to skip some of the valid matches when other overload
choice have generic parameters at the same parameter position.
The problem this is trying to solve is eager selection of operators
over unsupported disjunctions, when matching operators let's take
speculative information into account because it helps to make better
choices in this case.
The test was slow with hacks but now it's much faster - takes about
63k scopes to solve, it could be improved by introducing new overloads
of prefix `-` to stdlib.
Some of the disjunctions are not supported by the optimizers but
could still be a better choice than an operator. Using a non-score
based preference mechanism first allows us to make sure that
operator disjunctions are not selected too eagerly in some situations
when i.e. a member (supported or not) could be a better choice.
`isPreferable` currently targets only operators in result builder
contexts but it could be expanded to more uses in the future.
New ranking + selection algorithm suffered from over-eagerly selecting
operator disjunctions vs. unsupported non-operator ones even if the
ranking was based purely on literal candidates.
This change introduces a notion of a speculative candidate - one which
has a type inferred from a literal or an initializer call that has
failable overloads and/or implicit conversions (i.e. Double/CGFloat).
`determineBestChoicesInContext` would reset the score of an operator
disjunction which was computed based on speculative candidates alone
but would preserve favoring information. This way selection algorithm
would not be skewed towards operators and at the same time if there
is no no choice by to select one we'd still have favoring information
available which is important for operator chains that consist purely
of literals.
If there are no-same type requirements and parameters use
either concrete types or generic parameter types directly,
the optimizer should be able to handle ranking. Currently
candidate arguments are considered in isolation which makes
it impossible to deal with same-type requirements and
complex generic signatures.
