Given definition is no longer resolved to in mapped function usage site.

[sageserpent-open]

Compiler version

3.3.7 (also seen in 3.7.3)

Minimized code

//> using scala 3.3.7
//> using options -Wall -Werror

case class MergeResult[Element: Eq] private (segments: Seq[Segment[Element]]):

  def fuseWith(another: MergeResult[Element])(
      elementFusion: (Element, Element) => Option[Element]
  ): Option[MergeResult[Element]] =
    if segments.size != another.segments.size then None
    else
      Traverse[Seq]
        .traverse(segments.zip(another.segments))(_.fuseWith(_)(elementFusion))
        .map(MergeResult.apply)
        //               ^^^^^ Can't find the given for Eq[Any], despite there
        //                     being an Eq[Element] available.

Output

No given instance of type cats.kernel.Eq[Any] was found for a context parameter of method apply in object MergeResult
        .map(MergeResult.apply)

Expectation

This used to build under 3.3.6, now fails because the given for Eq[Element] is not used, rather a search for Eq[Any] takes place.

My expectation was that the explicit return type of Option[Element] should have forced the correct resolution of the given.

NOTE: changing the function application to MergeResult.apply[Element] works around this problem.

[Gedochao]

When posting compiler bugs, please include the dependencies and imports alongside the code.

I managed to guess that we're likely missing something along the lines of:

//> using dep org.typelevel::cats-core:2.13.0
import cats.kernel.Eq
import cats.Traverse
import cats.syntax.traverse.*

but I still can't figure out where's Segment from.
@sageserpent-open please edit the issue description with a self-contained snippet.

(not to mention that we'll likely need to minimize this outside of depending on cats-core, but that's the next step)

[sageserpent-open]

@Gedochao Oops - was in the middle of something else, completely forgot to make the Cats dependency explicit.

No, I don't use the Scala CLI - I build with SBT / IntelliJ. I did try using scala-cli, but was rewarded with:

Starting compilation server
Error: bloop.rifle.FailedToStartServerExitCodeException: Server failed with exit code 1
For more details, please see '.../scratches/.scala-build/stacktraces/1760693332-6033940442433224837.log'
Running
  scala-cli bloop output
might give more details.

I think one additional problem at a time is enough for me, please excuse the fast-and-loose approach. 😬

Ah, yes, Segment is missing too. To be honest I was hoping it would be obvious to you folks just looking at the error and shape of the code, but it's completely reasonable to expect something that builds, so here's a minimised example:

//> using dep org.typelevel::cats-core::2.9.0
//> using dep org.scala-lang.modules::scala-collection-contrib::0.4.0

import cats.{Eq, Traverse}

object ParameterisedWithTypeClassConstraint:
  enum Segment[Element: Eq]:
    case Resolved(elements: Seq[Element])(using eq: Eq[Element])
  end Segment

  given segmentEquality[Element](using
      elementEquality: Eq[Element]
  ): Eq[Segment[Element]] = ???
end ParameterisedWithTypeClassConstraint

case class ParameterisedWithTypeClassConstraint[Element: Eq] private (
    segments: Seq[ParameterisedWithTypeClassConstraint.Segment[Element]]
):

  def thisFailsToCompile: Option[ParameterisedWithTypeClassConstraint[Element]] =
    // This import seems to trigger the failure...
    import scala.collection.decorators.*

    Traverse[Seq]
      .sequence(
        Seq.empty[Option[ParameterisedWithTypeClassConstraint.Segment[Element]]]
      )
      .map(ParameterisedWithTypeClassConstraint.apply)

  def thisCompilesSuccessfully: Option[ParameterisedWithTypeClassConstraint[Element]] =
    // ... but only when the traversal is inlined.
    import scala.collection.decorators.*

    val intermediateExpression = Traverse[Seq].sequence(
      Seq.empty[Option[ParameterisedWithTypeClassConstraint.Segment[Element]]]
    )

    intermediateExpression
      .map(ParameterisedWithTypeClassConstraint.apply)
  end thisCompilesSuccessfully

  def thisAlsoCompilesSuccessfully: Option[ParameterisedWithTypeClassConstraint[Element]] = {
    // No import, no problem.
    Traverse[Seq]
      .sequence(
        Seq.empty[Option[ParameterisedWithTypeClassConstraint.Segment[Element]]]
      )
      .map(ParameterisedWithTypeClassConstraint.apply)
  }

  def thisCompilesSuccessfullyToo
  : Option[ParameterisedWithTypeClassConstraint[Element]] =
    // An explicit type on the constructor application also fixes this.
    import scala.collection.decorators.*

    Traverse[Seq]
      .sequence(
        Seq.empty[Option[ParameterisedWithTypeClassConstraint.Segment[Element]]]
      )
      .map(ParameterisedWithTypeClassConstraint.apply[Element])
    //                                               ^^^^^^^^^
  end thisCompilesSuccessfullyToo

end ParameterisedWithTypeClassConstraint

I'm glad I did miminise this, because it shows some kind of interplay between the import of the decorators and the Cats traversal. Why this also depends on whether or not the Cats traversal is inlined or bound to a local variable is beyond me.

Again, this wasn't present in Scala 3.3.6 but is in 3.3.7.

@tgodzik had a theory about this on the discussion over here: https://users.scala-lang.org/t/mapping-with-a-function-that-takes-a-using-argument-in-scala-3-3-7/12076/7

[sageserpent-open]

(not to mention that we'll likely need to minimize this outside of depending on cats-core, but that's the next step)

I did try substituting an equivalently typed expression instead of the Cats traversal, but failed to duplicate the error. Given that inlining the traversal expression seems to be connected, I imagine you'll either have to stick with Cats for the time being or substitute with an equivalent expression.

I'll leave the latter choice as an exercise to the reader.

[Gedochao]

No, I don't use the Scala CLI - I build with SBT / IntelliJ. I did try using scala-cli, but was rewarded with:

Starting compilation server
Error: bloop.rifle.FailedToStartServerExitCodeException: Server failed with exit code 1
For more details, please see '.../scratches/.scala-build/stacktraces/1760693332-6033940442433224837.log'
Running
  scala-cli bloop output
might give more details.

@sageserpent-open Feel free to raise it at https://github.com/VirtusLab/scala-cli/issues / https://github.com/scalacenter/bloop/issues and we can debug it there, of course, but for a fast and loose approach...
When in doubt, you can always skip Bloop with --server=false:

scala-cli . --server=false

[sageserpent-open]

@sageserpent-open Feel free to raise it at https://github.com/VirtusLab/scala-cli/issues / https://github.com/scalacenter/bloop/issues and we can debug it there, of course, but for a fast and loose approach...
When in doubt, you can always skip Bloop with --server=false:

For the sake of completeness, I tried that and encountered an error regarding Java 21 being an invalid choice. That made me think about the provenance of scala-cli on my machine and it turned out to be quite an old version, 1.0.0.

Upgrading to 1.9.1 fixed that problem, so Scala CLI reproduces the reported bug. I've golfed the code down slightly and edited the comment above to reflect that.

[Gedochao]

That made me think about the provenance of scala-cli on my machine and it turned out to be quite an old version, 1.0.0.

...yeah, that's somewhat expected if you were running such an old version 😅

[Gedochao]

Last good 3.3 LTS release: 3.3.7-RC1-bin-20250726-068c6c7-NIGHTLY
First bad 3.3 LTS release release: 3.3.7-RC1-bin-20250729-e9954cc-NIGHTLY
(the bisect script isn't very useful for finding the exact backported commit because of #24220)

Last good release: 3.7.3-RC1-bin-20250717-fb66af2-NIGHTLY
First bad release: 3.7.3-RC1-bin-20250718-42fdd76-NIGHTLY
45f7ef6 is the first bad commit (#23532)
cc @odersky