`@main` annotation may conflict with method called `main`

[propensive]

It is reasonably likely that at least some users would choose to name a program's main method, annotated with the @main annotation, as literally main, like so:

@main def main(): Unit = println("Hello, World!")

Unfortunately, compiling such an example twice, with,

dotc hello.scala
dotc hello.scala

will yield one successful compilation and then,

-- [E007] Type Mismatch Error: hello.scala:1:0 ---------------------------------
1 |@main def main(): Unit = println("Hello World")
  |^^^^^
  |Found:    main
  |Required: scala.annotation.Annotation
1 error found

This occurs because the compiled class called main shadows the Annotation class main. But the effect on the user is that they receive a surprising and misleading error message, not least because "it worked the first time, and failed the second time, with nothing apparently changing in between". This could be a very bad user experience at the first try.

An earlier proposal used a program keyword instead of @main, which could have avoided this. Or alternatively an annotation with a different name could be used.

A less satisfactory, but more actionable solution (given how close we are to release), might be to provide a special-case for the @main annotation to print a more meaningful error message to avoid beginners getting confused.

(My own preference would be to introduce a new soft keyword, such as program or main.)

[nafg]

Ha, I just hit this. A more consistent and conservative solution would be: 1) Detect the conflict on the first compile. That is, if top-level methods shadow classes then the first time around as well @main should refer to the method not scala.main 2) The error message for all such errors should be more detailed. If the thing after the at sign is not an annotation, what is it? Some other class? Where is it defined? If as soon as I tried to do @main def main, I got a compiler error that said expected annotation but main is defined as a method on line X in file Y (or package / object Y, ideally with the line that imports it), I wouldn't be confused -- the solution would be obvious. (For bonus points, it could suggest renaming the method or the import if it sees that it's shadowing a valid candidate.)

…

On Sun, Nov 1, 2020, 7:48 AM Jon Pretty ***@***.***> wrote: It is reasonably likely that at least some users would choose to name a program's main method, annotated with the @main annotation, as literally main, like so: @main def main(): Unit = println("Hello, World!") Unfortunately, compiling such an example *twice*, with, dotc hello.scala dotc hello.scala will yield one successful compilation and then, -- [E007] Type Mismatch Error: hello.scala:1:0 --------------------------------- 1 ***@***.*** def main(): Unit = println("Hello World") |^^^^^ |Found: main |Required: scala.annotation.Annotation 1 error found This occurs because the compiled class called main shadows the Annotation class main. But the effect on the user is that they receive a surprising and misleading error message, not least because "it worked the first time, and failed the second time, with nothing apparently changing in between". This could be a very bad user experience at the first try. An earlier proposal used a program keyword instead of @main, which could have avoided this. Or alternatively an annotation with a different name could be used. A less satisfactory, but more actionable solution (given how close we are to release), might be to provide a special-case for the @main annotation to print a more meaningful error message to avoid beginners getting confused. (My own preference would be to introduce a new soft keyword, such as program or main.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10137>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUCBEFLCV7MUMJ27ZWDSNVKKRANCNFSM4TGQE44A> .

[odersky]

Another choice would be to be resolve annotations specially. When processing an annotation like @main the compiler could search scala.annotation in addition to scala, java.lang, and Predef. Then @main would resolve to the annotation, even if a class file named main exists.

EDIT: No that would not work. main is defined in scala anyway, not scala.annotation.

[odersky]

Detect the conflict on the first compile. That is, if top-level methods
shadow classes then the first time around as well @main should refer to the
method not scala.main

That does not work either. @main is a reference to a type, it cannot refer to a method. The problem is that we generate
later a class called main which shadows the annotation.

So the real problem is that if a method foo is annotated with @main we also claim the name foo in the type namespace. So if that type name is already taken, we get potentially different behavior on recompile.

[nafg]

On Fri, Nov 6, 2020 at 4:09 AM odersky ***@***.***> wrote: Detect the conflict on the first compile. That is, if top-level methods shadow classes then the first time around as well @main <https://github.com/main> should refer to the method not scala.main That does not work either. @main <https://github.com/main> is a reference to a type, it cannot refer to a method.

I know it can't *refer* to a method. But the compiler could be smart enough and throw a special error for this case, since it knows one is coming down the path anyway.

…

The problem is that we generate later a *class* called main which shadows the annotation. So the real problem is that if a method foo is annotated with @main we also claim the name foo in the type namespace. So if that type name is already taken, we get potentially different behavior on recompile. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10137 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUFJSKB5YUA7AMFDONDSOO4LFANCNFSM4TGQE44A> .

[odersky]

It now emits a warning. For instance

-- Warning: tests/neg/i10137.scala:2:12 -------------------------------------------------------
2 |  @main def main(): Unit = println("Hello, World!") // error
  |            ^
  |            The class `foo.main` generated from `@main` will shadow the existing class main in package scala.
  |            The existing definition might no longer be found on recompile.
-- Warning: tests/neg/i10137.scala:4:10 -------------------------------------------------------
4 |@main def List(): Unit = println("List") // error
  |          ^
  |          The class `List` generated from `@main` will shadow the existing type List in package scala.
  |          The existing definition might no longer be found on recompile.