activate constrainResult fix in 3.4

[bishabosha]

fixes #18174

Release Notes

Type inference has changed for inline methods in 3.4, which can cause a source incompatibility at the call site. The previous behaviour can be recovered in an affected file with

import scala.language.`3.3`

alternatively the definition can changed to transparent inline, but as this is a TASTy breaking change it is not a default recommendation. (Also inline should be preferred when possible over transparent inline for reduced binary size)

[julienrf]

Thank you!

[bishabosha]

@sjrd and @julienrf asking for advice on the release notes clause

[julienrf]

I am not sure whether the note should belong to the section “Error reporting improvements” or “Changes with compatibility issues”, but here is a first suggestion:

Before 3.4.0, compilation errors were sometimes containing incorrect suggestions. Here is an example taken from the bug report #9685:

  import munit.FunSuite

  class Example extends FunSuite {
    1.asdf
//  ^^^^^^
// value asdf is not a member of Int, but could be made available as an extension method.
//
// The following import might make progress towards fixing the problem:
//
//    import munit.Clue.generate
  }

In this example, the second part of the error message, which suggest adding an import, is incorrect. Adding the suggested import would not help here.

This issue is fixed in Scala 3.4.0. The error message does not anymore suggest irrelevant imports.

However, the fix changed the way the result types of calls to inline methods are inferred, which could cause compilation errors when upgrading to Scala 3.4.0. You can check if your Scala 3.3.x project would compile with the new type inference behavior by adding the compiler option -source future. In case some files of your project do not compile with Scala 3.4.0 anymore, you can switch back to the old behavior by adding import scala.language.`3.3` in the impacted files, or, preferably, fix the issue by adding more explicit types (so that the compiler does not need to infer them), or, in last resort, by making the method transparent inline instead of just inline.

That being said, it seems #18130, which introduces the -source future behavior has not been backported to Scala 3.3, so the -source future trick indicated above might not work. Unless I missed something?