Improve assertion error message for Apply and TypeApply

[nicolasstucki]

These are valid prefixes for a TypeApply in the same way they are for an Apply.

See #16861 (comment)

[benhutchison]

@nicolasstucki thank you 🙏

[dwijnand]

@nicolasstucki I fixed the root cause in #18719, and then I'm tweaking that in #18727.

[nicolasstucki]

@nicolasstucki I fixed the root cause in #18719, and then I'm tweaking that in #18727.

Ok, I changed this PR to only improve the assertion failure message.

[dwijnand]

We should use the i interpolator, so it's pretty-printed.

[nicolasstucki]

No. We need to see the exact AST. Otherwise we would not see the difference between a TypeApply and Inlined; or some similar cases where show is equivalent.

[nicolasstucki]

Another way to see this is as a match error. Maybe I could encode it in a simpler way and make it fail with an equivalently useful output. I will try that.

[nicolasstucki]

The alternative is

  def TypeApply(fn: Tree, args: List[Tree])(using Context): TypeApply = fn match
    case Block(Nil, expr) =>
      TypeApply(expr, args)
    case _: RefTree | _: GenericApply =>
      ta.assignType(untpd.TypeApply(fn, args), fn, args)
    case _ if ctx.reporter.errorsReported => // We expect the error. Otherwise, we want to throw a match error.
      ta.assignType(untpd.TypeApply(fn, args), fn, args)

But this one does duplicate ta.assignType(untpd.TypeApply(fn, args), fn, args). I find the current one clearer.

[dwijnand]

How about i"Illegal TypeApply function prefix: $fn (${fn.className})" then? Don't need the verbose nested trees, I would think.

[nicolasstucki]

Given the history of the failure, I would argue otherwise. Knowing which tree caused the issue in one of those large projects can be helpful in pinpointing the likely source of the problem.