`@nowarn` on early initializer does not work inside class with annotation macro

[pweisenburger]

Reproduction steps

Using Scala 2.13.7 with -Ymacro-annotations, define a macro annotation that just leaves the annotated class unchanged:

package test

import scala.annotation.StaticAnnotation
import scala.language.experimental.macros
import scala.reflect.macros.blackbox

class Test extends StaticAnnotation {
  def macroTransform(annottees: Any*): Any = macro TestImpl.test
}

object TestImpl {
  def test(c: blackbox.Context)(annottees: c.Tree*): c.Tree = annottees.head
}

Apply the annotation as in the following:

@test.Test class C {
  new { val v = 1 } with AnyRef: @scala.annotation.nowarn("msg=early initializers")
}

Problem

The compiler generates the following warnings:

early initializers are deprecated; they will be replaced by trait parameters in 3.0, see the migration guide on avoiding var/val in traits.
  new { val v = 1 } with AnyRef: @scala.annotation.nowarn("msg=early initializers")
      ^
@nowarn annotation does not suppress any warnings
  new { val v = 1 } with AnyRef: @scala.annotation.nowarn("msg=early initializers")
                                  ^

I would expected that the annotation actually suppresses the first warning (making also the second warning void). Hence, I would expect compilation without warnings. In particular, there is no warning when leaving out the macro annotation.

[som-snytt]

It looks like the expanded tree does not receive a range position, so the nowarn doesn't either. Therefore the nowarn does not enclose the target message.

Maybe c.macroApplication.pos is still the correct incoming range.

[pweisenburger]

You are right that the expanding tree class C { ... } does not have a range position (it actually seems to have NoPosition), but the "annotation" subtree has one.

There is a tree tree @ Annotated(annot, arg) where annot is the new scala.annotation.nowarn("msg=early initializers") tree and arg is the new { val v = 1 } with AnyRef tree. tree has position RangePosition(..., 23, 55, 104), arg has position RangePosition(..., 23, 23, 52) and tree.pos.includes(arg.pos)is true.

So I am under the impression that that nowarn does enclose the target message, correct?

In my actual code, I would also be able to traverse the tree and fix the positions but it seems the positions are correct and the problem might be a different one. Am I right?

This is even more of a problem due to sbt/sbt#6720 which causes compilation using SBT to fail on Windows (because of the wrong warning). Fixing or working around either of these issues would already help me.

[som-snytt]

Apologies, I'm pretty sure my previous comment applied to the second thing I tested, with the nowarn on the class def. Or I guess I also set it back again. If the nowarn is "registered" with a position, and a warning is emitted with an offset position, I think it should still check as enclosed? Not an expert, but I can add some printlns to check that.

import annotation._

//@scala.annotation.nowarn("msg=early initializers")
@test.Test
class C {
    new { val v = 1 } with AnyRef: @nowarn
    //new { val v = 1 } with AnyRef: @scala.annotation.nowarn("msg=early initializers")
}

Also we ought not omit to complain that having to say annotation for common annotations is redundant and annoying. Do you hear me raging against you, powers that be?

Edit: Actually I can't reproduce it? I guess I broke the macro expansion, but how?

Edit: I had dropped -Ymacro-annotations when compiling the macro. It's necessary when compiling everything, macro and expandee.

[som-snytt]

The nowarn is registered with

register nowarn at source-/home/amarki/projects/scala/test/files/pos/t12498/Client_2.scala,line-4,offset=67

which is an offset not a range.

I assumed (last time) that the paradise infrastructure wasn't respecting rangepos.

[som-snytt]

The docs say you better

@compileTimeOnly("requires -Ymacro-annotations to expand")

or folks will wonder why their expansion failed to expand.

It seems to me they could auto-detect that an annotation with a macroTransform method requires the option, and at least fail fast.

[som-snytt]

maybe focusing at https://github.com/scala/scala/blob/2.13.x/src/compiler/scala/tools/nsc/typechecker/Macros.scala#L777 where there is a long comment. "this loss of position fidelity shouldn't cause any real problems."

[pweisenburger]

"this loss of position fidelity shouldn't cause any real problems."

Ha okay, that's what someone thought 8 years ago ;-)

Thanks for investigating this!

[som-snytt]

Footnote: syms get an attachment indicating their expansion, but trees do not get an attachment with the "original", where original positions could be recovered.