given declarations with & do not compile as expected

[amaalali]

Compiler version

3.3.5

Minimized code

trait A:
  def a: Unit

trait B:
  def b: Unit

class ABImpl extends A, B:
  def a: Unit = println("a")
  def b: Unit = println("b")

// Compiles when a type alias is used
type AB = A & B
given namedGivenWithTypeAlias: AB = ABImpl()
given AB = ABImpl()

// Compiles with parentheses
given namedGivenWithParentheses: (A & B) = ABImpl()
given (A & B) = ABImpl()

// Does not compile when & is used inline
given namedGivenInline: A & B = ABImpl()
given A & B = ABImpl()

Output

[error] ./test.scala:24:27
[error] 'with' expected, but identifier found
[error] given namedGivenInline: A & B = ABImpl()
[error]                           ^
[error] ./test.scala:25:9
[error] 'with' expected, but identifier found
[error] given A & B = ABImpl()
[error]         ^
Error compiling project (Scala 3.3.5, JVM (21))

Expectation

given namedGivenInline: A & B = ABImpl() and given A & B = ABImpl() should compile as valid given declarations.

[amaalali]

This doesn't seem to be an issue in 3.6.3

Minimized code

trait A:
  def a: Unit

trait B:
  def b: Unit

class ABImpl extends A, B:
  def a: Unit = println("a")
  def b: Unit = println("b")

// Compiles when a type alias is used
type AB = A & B
given namedGivenWithTypeAlias: AB = ABImpl()
given AB = ABImpl()


// Compiles with parentheses
object A:
  given namedGivenWithParentheses: (A & B) = ABImpl()
object B:
  given (A & B) = ABImpl()

// Does not compile when & is used inline
object C:
  given namedGivenInline: A & B = ABImpl()

object D:
  given A & B = ABImpl()

(modification of the original snippet was required as 3.6.3 returns a different error)

[WojciechMazur]

The fix, available since 3.6, was introduced probably in #21208 and #21668, both of which are not backportable to Scala 3.3 LTS.
To fix it in the LTS we'd need to carefully adopt some of the changes introduced in these 2 PR without introducing any changes related to new givens syntax.

[Gedochao]

@WojciechMazur @tgodzik
Backporting those PRs to the LTS was rejected previously.
Is this a wontfix for the LTS, or should we re-attempt this?

[WojciechMazur]

I'd say that's a won't fix.
The general policy for LTS was that we focus on backporting changes from Next, instead of actively developing the LTS branch. If the fix is possible, but does require a dedicated work based on existing changes (like in this case) we'd welcome an external contributors willing to create a PR that might be merged into LTS if it does not couse any new regressions. I'm afraid we don't have enough resources to assign dedicated developer to work on this right now.
It might become a topic for compiler spree

[Gedochao]

Alright. I'm closing it for now then.