Invent given pattern name in for comprehension

[som-snytt]

Fixes #23119

A given pattern in a for comprehension results in a fresh val in the body of the mapping function, but it should have the same (arbitrary) name as in the rest of the expansion.

This commit gives the given its usual given name (in makeIdPat) so that the unused check can check it.

Currently, without -preview, showing that $1$ is called given_Int by typer:

➜  scala-cli repl --server=false -S 3.7.2-RC1 -Vprint:typer,refchecks -Wunused:all
Welcome to Scala 3.7.2-RC1 (17.0.15, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> for given Int <- 1 to 2; j: Int = summon[Int] yield j
1 warning found
[[syntax trees at end of                     typer]] // rs$line$1
package <empty> {
  final lazy module val rs$line$1: rs$line$1 = new rs$line$1()
  final module class rs$line$1() extends Object() { this: rs$line$1.type =>
    val res0: IndexedSeq[Int] =
      intWrapper(1).to(2).map[(Int, Int)]((x$1: Int) =>
        x$1:Int @unchecked match
          {
            case given $1$ @ _:Int =>
              val j: Int = $1$
              Tuple2.apply[Int, Int]($1$, j)
          }
      ).map[Int]((x$1: (Int, Int)) =>
        x$1:(x$1 : (Int, Int)) @unchecked match
          {
            case Tuple2.unapply[Int, Int](given given_Int @ _:Int, j @ _:Int)
               => j:Int
          }
      )
  }
}

Without -preview, this commit:

scala> for given Int <- 1 to 2; j: Int = summon[Int] yield j
[[syntax trees at end of                     typer]] // rs$line$1
package <empty> {
  final lazy module val rs$line$1: rs$line$1 = new rs$line$1()
  final module class rs$line$1() extends Object() { this: rs$line$1.type =>
    val res0: IndexedSeq[Int] =
      intWrapper(1).to(2).map[(Int, Int)]((x$1: Int) =>
        x$1:Int @unchecked match
          {
            case given given_Int @ _:Int =>
              val j: Int = given_Int
              Tuple2.apply[Int, Int](given_Int, j)
          }
      ).map[Int]((x$1: (Int, Int)) =>
        x$1:(x$1 : (Int, Int)) @unchecked match
          {
            case Tuple2.unapply[Int, Int](given given_Int @ _:Int, j @ _:Int)
               => j:Int
          }
      )
  }
}

With -preview, the tupling map is eliminated early:

scala> for given Int <- 1 to 2; j: Int = summon[Int] yield j
[[syntax trees at end of                     typer]] // rs$line$1
package <empty> {
  final lazy module val rs$line$1: rs$line$1 = new rs$line$1()
  final module class rs$line$1() extends Object() { this: rs$line$1.type =>
    val res0: IndexedSeq[Int] =
      intWrapper(1).to(2).map[Int]((x$1: Int) =>
        x$1:Int @unchecked match
          {
            case given given_Int @ _:Int =>
              val j: Int = given_Int
              j:Int
          }
      )
  }
}

[som-snytt]

@sjrd Minimized commit!

[som-snytt]

I knew I'd fixed the spelling of anonympus somewhere, though I am rather sorry to have fixed it.

[sjrd]

I think this will break scenarios where there are two given captures for two types where inventGivenName produces the same name. For example a given foo: List[Option[Int]] and a given bar: List[Option[String]].

We should at the very least add a test for such a situation, make sure that both can still be resolved.

[som-snytt]

@sjrd I considered that because I just noted elsewhere (#23832 (comment)) that local givens can have clashing names but could just as well have fresh names (modulo code can refer to the invented name).

I'll add tests a test for clashing and for referring.

[som-snytt]

Actually, as shown in the -Vprint above, the invented names are already used in map desugaring, so

scala> for x <- 1 to 2; given Option[List[String]] = Some(List(x.toString)); given Option[List[Int]] = Some(List(x)) yie
ld summon[Option[List[String]]]
-- [E005] Naming Error: --------------------------------------------------------
1 |for x <- 1 to 2; given Option[List[String]] = Some(List(x.toString)); given Option[List[Int]] = Some(List(x)) yield summon[Option[List[String]]]
  |                                                                      ^^^^^^^^^^^^^^^^^^^^^^^
  |                             duplicate pattern variable: given_Option_List
  |

because

      ).map[Option[List[String]]]((
        x$1: (Int, Option[List[String]], Option[List[Int]])) =>
        x$1:(x$1 : (Int, Option[List[String]], Option[List[Int]])) @unchecked
           match
          {
            case
              Tuple3.unapply[Int, Option[List[String]], Option[List[Int]]](
                x @ _, given given_Option_List @ _:Option[List[String]],
                given given_Option_List @ _:Option[List[Int]])
             => given_Option_List:Option[List[String]]
          }
      )

It progresses to clashing locals.

  |given_Option_List is already defined as given instance given_Option_List

But it would be best if the additional help from "double definition" were available for these cases. (Because givens are so mysterious? Because anonymous givens are common and fragile?)

[mr-git]

Maybe there is a way to name givens in for-comprehension? Like:

for given j: Int <- 1 to 2 yield j

or something like this?

I failed to find a way to set dedicated name for a given.

[som-snytt]

@mr-git See the test, the syntax is name @ given T for a pattern.

In the summary it's called Pattern2.

Edit: don't be fooled by the way it prints under -Vprint.

[mr-git]

@som-snytt thank you so much! I couldn't imagine such a way to write it - even after using case implicit0(x: X) <- ??? in many places!

Only place where I found such usage is Pattern-Bound Given Instances, but I didn't imagine that it could be used in for-comprehension too. Sadly there are zero examples for such use-case in docs.

And IDEA doesn't provide hint to change from:

for {
  //...
  given X = getX()
  x = summon[X]
  //..

to

for {
  //...
  x @ given X = getX()
  //..

Honestly, I don't know many language users, who would go through the syntax summary.

[som-snytt]

@mr-git thanks, I'd forgotten the name for it, but that was the answer to "what is the replacement for f { implicit p => }?"

That is, f { case p @ given P => }, though the idiomatic answer is "use context functions".

I found an example #12676

My point is that it is a FAQ but maybe not written up in a helpful document. I don't see it in the migration guide (at a glance).