Do not lift annotation arguments

[mbovel]

When typing

class Fork(value: Int = -1, jvmArgs: Array[String] = Array("nope")) extends annotation.Annotation
@Fork(jvmArgs = Array("I'm", "hot")) class Test() extends Object() {}

the annotation arguments are currently lifted, so that the annotation tree of @Fork(jvmArgs = Array("I'm", "hot")) becomes:

{
  val jvmArgs$1: Array[String] = Array.apply[String](["I\'m","hot" : String]*)(scala.reflect.ClassTag.apply[String](classOf[String]))
  val value$1: Int @uncheckedVariance = Fork.$lessinit$greater$default$1
  new Fork(value$1, jvmArgs = jvmArgs$1)
}

This breaks the assumption that annotation trees are always of the form new annot(…).

It's currently worked around in allTermArguments where we ignore block statements:

scala3/compiler/src/dotty/tools/dotc/ast/TreeInfo.scala

Lines 144 to 148 in 0afabd6

	def allTermArguments(tree: Tree): List[Tree] = unsplice(tree) match {
	case Apply(fn, args) => allTermArguments(fn) ::: args
	case TypeApply(fn, args) => allTermArguments(fn)
	case Block(_, expr) => allTermArguments(expr)
	case _ => Nil

This however falls short in different situations; as this completely ignore argument trees.

---

To fix this, I propose to not lift argument that are annotation arguments.

There is precedent for this: we actually already do it for Java annotations:

scala3/compiler/src/dotty/tools/dotc/typer/Applications.scala

Lines 502 to 518 in 0afabd6

	protected def needLiftFun: Boolean = {
	def requiredArgNum(tp: Type): Int = tp.widen match {
	case funType: MethodType =>
	val paramInfos = funType.paramInfos
	val argsNum = paramInfos.size
	if (argsNum >= 1 && paramInfos.last.isRepeatedParam)
	// Repeated arguments do not count as required arguments
	argsNum - 1
	else
	argsNum
	case funType: PolyType => requiredArgNum(funType.resultType)
	case tp => args.size
	}
	!isJavaAnnotConstr(methRef.symbol) &&
	args.size < requiredArgNum(funType)
	}

[mbovel]

Oops, I created the branch mb/annots/default-args on this repo, hence the duplicate CI jobs, my mistake, I meant to push it on my fork. At least we'll be doubly-sure that it works 😄

[tgodzik]

@mbovel Should we gather your changes for annotations and put that in one section in release notes? I think there were more PRs about it?

[mbovel]

Why not! I can tag annotations-related PR with the area:annotations label if that helps.

[tgodzik]

I also added release-notes label so it's not lost