`transparent` modifier breaks beta-reduction

[t9dupuy]

Compiler version

3.6.3

Minimized code

Using the transparent modifier seems to break beta-reduction (it doesn't happen) for lambda functions

// Non poly example
transparent inline def apply1[B](inline f: Int => B): B = f(1)
inline def aa: Int => Int = double

def double(i: Int) = i * 2

val a = apply1(aa)
// Got: val a: Int = ((i: Int) => double(i):(Int => Int)).apply(1)
// Expected: val a: Int = double(1):Int

// Poly example
transparent inline def applyInt[B](inline f: [T] => () => B): B = f[Int]()
inline def bb: [T] => () => Int = [T] => () => myIntPoly[T]

def myIntPoly[T]: Int = 1

val b = applyInt(bb)
// Got: val b: Int = ([T >: Nothing <: Any] => () => myIntPoly[T]:([T] => () => Int)).apply[Int]()
// Expected: val b: Int = { type T = Int; myIntPoly[T] }:Int

The code was inspected using -Xprint:type,inlining.
The expected code can reproduced by removing transparent and fits the beta-reduction comment specification given here

scala3/compiler/src/dotty/tools/dotc/transform/BetaReduce.scala

Lines 54 to 74 in 7ac31d0

	/** Rewrite an application
	*
	* ((x1, ..., xn) => b)(e1, ..., en)
	*
	* to
	*
	* val/def x1 = e1; ...; val/def xn = en; b
	*
	* where `def` is used for call-by-name parameters. However, we shortcut any NoPrefix
	* refs among the ei's directly without creating an intermediate binding.
	*
	* Similarly, rewrites type applications
	*
	* ([X1, ..., Xm] => (x1, ..., xn) => b).apply[T1, .., Tm](e1, ..., en)
	*
	* to
	*
	* type X1 = T1; ...; type Xm = Tm;val/def x1 = e1; ...; val/def xn = en; b
	*
	* This beta-reduction preserves the integrity of `Inlined` tree nodes.
	*/

Output

See comments in minimized code.

Expectation

The beta reduction should be properly applied for transparent methods.

[hamzaremmal]

BetaReduction happens after inlining in the pipeline:

scala3/compiler/src/dotty/tools/dotc/Compiler.scala

Line 67 in e592b37

new BetaReduce, // Reduce closure applications

If you actually print the AST after beta-reduction (-Xprint:betaReduce), you can observe that the reduction happens correctly.
As far as I'm concerned, this should be enough to close this ticket, but I'm wondering about any impact on the spec of the macro system...

[smarter]

BetaReduction happens after inlining in the pipeline

BetaReduce is actually called from inside the inliner too:

scala3/compiler/src/dotty/tools/dotc/inlines/Inliner.scala

Lines 891 to 895 in 094e4fb

	specializeEq(inlineIfNeeded(constToLiteral(BetaReduce(super.typedApply(tree, pt))), pt, locked))
	override def typedTypeApply(tree: untpd.TypeApply, pt: Type)(using Context): Tree =
	val locked = ctx.typerState.ownedVars
	val tree1 = inlineIfNeeded(constToLiteral(BetaReduce(super.typedTypeApply(tree, pt))), pt, locked)

I don't have an example at hand, but this does have an impact on the behavior of summonInline for example so it's not just an optimization.

[smarter]

Here's an example where the lack of beta-reduction with transparent leads to an error:

import scala.compiletime.requireConst

object Test:
  inline def nonTransp(inline f: Int => Int): Int = f(1)
  transparent inline def transp(inline f: Int => Int): Int = f(1)
  inline def double: Int => Int = x => x * 2

  def test =
    requireConst(nonTransp(double)) // OK
    requireConst(transp(double)) // error:
                                 // expected a constant value but found: (
                                 //   {
                                 //     def $anonfun(x: Int): Int = x.*(2)
                                 //     closure($anonfun)
                                 //   }
                                 // :(Int => Int)).apply(1)