Make overload pruning based on result types less aggressive

[smarter]

adaptByResult was introduced in 2015 in
54835b6 as a last step in overloading resolution:

Take expected result type into account more often for overloading resolution

Previously, the expected result type of a FunProto type was ignored and taken into
account only in case of ambiguities. arrayclone-new.scala shows that this is not enough.
In a case like

val x: Array[Byte] = Array(1, 2)

we typed 1, 2 to be Int, so overloading resulution would give the Array.apply of
type (Int, Int*)Array[Int]. But that's a dead end, since Array[Int] is not a subtype
of Array[Byte].

This commit proposes the following modified rule for overloading resulution:

A method alternative is applicable if ... (as before), and if its result type
is copmpatible with the expected type of the method application.

The commit does not pre-select alternatives based on comparing with the expected
result type. I tried that but it slowed down typechecking by a factor of at least 4.
Instead, we proceed as usual, ignoring the result type except in case of
ambiguities, but check whether the result of overloading resolution has a
compatible result type. If that's not the case, we filter all alternatives
for result type compatibility and try again.

In i21410.scala this means we end up checking:

F[?U] <:< Int
(where ?U is unconstrained, because the check is done without looking at the
argument types)

The problem is that the subtype check returning false does not mean that there is no instantiation of ?U that would make this check return true, just that type inference was not able to come up with one. This could happen for any number of reason but commonly will happen with match types since inference cannot do much with them.

We cannot avoid this by taking the argument types into account, because this logic was added precisely to handle cases where the argument types mislead you because adaptation isn't taken into account. Instead, we can approximate type variables in the result type to trade false negatives for false positives which should be less problematic here.

Fixes #21410.

[dwijnand]

Want to add your Tuple.Map example, as another case?

[smarter]

The only test failure is in monocle:

[error] -- Error: /__w/scala3/scala3/community-build/community-projects/Monocle/core/shared/src/test/scala-3.x/monocle/focus/ComposedFocusTest.scala:42:62 
[error] 42 |    val addressLens: AppliedLens[User, Address] = elise.focus(_.address)
[error]    |                                                              ^^^^^^^^^
[error]    |too many arguments for method focus in trait AppliedFocusSyntax: (): monocle.AppliedIso[From, From]
[error] one error found
[error] (coreJVM / Test / compileIncremental) Compilation failed
[error] Total time: 22 s, completed Oct 10, 2024 2:52:16 AM

[dwijnand]

Basically LGTM to merge, but 1 question about the isInlineable change.

[tgodzik]

Is it possible to port this to LTS, any opinions? @smarter @dwijnand

[WojciechMazur]

We have a couple of project that started to fail due this change. I don't yet have a minimization, but I'll create a dedicated issue as soon as I'll have one. Here are the logs project-wise bisect of darrenjw/scala-smfsb

https://github.com/VirtusLab/community-build3/actions/runs/13631644315/job/38100526097

Other project that might be related can be found in this report in Projects with last successful builds using Scala 3.7.0-RC1-bin-20250219-345b2da-NIGHTLY section