Scala 3 generated @main function is generated in package scope

[ekrich]

Compiler version

Scala 3

Minimized code

Suppose you are converting a Scala 2 application that has 2 main methods in the same package. This is not that uncommon as you may put applications in a app package. Here is the code, put in the same file for simplicity for the issue.

package app

object Foo {
    def main(args: Array[String]): Unit = println("Foo")
}

object Bar {
  def main(args: Array[String]): Unit = println("Bar")
}

Now you are converting this Scala 3 or just happen to want to add another application and you like the name main for your entry point as you are used to that convention. You convert the args using the documentation as you would get an conversion error No given instance ... if you left it as an Array[String].

package app

object Foo {
    @main def main(args: String*): Unit = println("Foo")
}

object Bar {
  @main def main(args: String*): Unit = println("Bar")
}

Output

Now this second example doesn't compile with a main is already defined as main ... error pointing to one or the other application that was compiled first.

Expectation

Generated or synthetic code should be scoped to the scope it is found in. It seems weird that code found in object scope is generated in package scope. This may be a more advanced way of thinking about this. The overall point is this is really surprising and bound to catch people because of the overall ergonomics.

There is also an additional surprise as follows:

package baz

object Bar {
  @main def main(): Unit = println("main Bar")
  @main def bar(): Unit = println("bar Bar")
}

Results in a warning (maybe for case insensitive file systems or something).

warn] 9 |object Bar {
[warn]   |       ^
[warn]   |Not generating the static forwarders of Top(baz.Bar) because its name differs only in case from the name of another class or trait in this compilation unit.

Note that main functions are not really special in Java except for the signature. They can be called by other code like a normal function.

I know the intent was to try and make entry points easier, nicer, and more flexible with less boiler plate. These sort of "edge" cases or just stuff people may try to do will be very unexpected.

Thanks.

[bishabosha]

I wouldn't say this is a bug - it was documented to behave this way: https://docs.scala-lang.org/scala3/reference/changed-features/main-functions.html

A @main annotated method can be written either at the top-level or in a statically accessible object. The name of the program is in each case the name of the method, without any object prefixes.

either way, changing the behaviour would be not backwards compatible - or we need a way to restore the old behaviour for those that need it

[ekrich]

Yes, I agree. Feel free to categorize it appropriately.

Overall to me, it seems to just sort of defy the normal idea of scope. Top level scope is a different thing. Like I said above, I don't think it is that unusual to have more than one app in the same package.

I like the typed arguments but I'm wondering if this will cause others troubles too, when the whole idea was to make things easier with less boilerplate.

[Gedochao]

I'm not sure if we want to change this behaviour, effectively breaking backwards compatibility... And I'm not even convinced if having multiple functions annotated as @main in a single codebase is even a good idea. But I see what you mean, there definitely would be a usecase.

As a middleground what I'm thinking is, maybe it'd be sufficient to improve the warnings to make this predictable?
What I mean is, for this example:

package baz

object Bar {
  @main def main(): Unit = println("main Bar")
  @main def bar(): Unit = println("bar Bar")
}

We currently (3.6.0-RC1-bin-20240807-54344a1-NIGHTLY) warn like this:

[warn] ./repro.scala:3:8
[warn] Generated class baz.Bar differs only in case from baz.bar.
[warn]   Such classes will overwrite one another on case-insensitive filesystems.
[warn] object Bar {
[warn]        ^

The warning about generated classes doesn't explain the core issue to the user, maybe we could warn specifically for the duplicated @main here?

[bjornregnell]

My students have made all sorts of unaniticipated usages of @main-funcs over the last semesters with Scala 3 -- I try to solve this by saying that the should not name their @main main and have unique names across their code base.

A good warning with good hints of how to solve the issue would be nice.

(We use top-level @main almost always now, but the story on the legacy with actual main with string array in relation to what the JVM requires needs to be told eventually when they have gotten a bit further, so that students know how to interpret what a main actually is and how to get out of strange edge cases like this...)

[ekrich]

Realistically, you can't have 2 mains (functions with the same signature) at any scope level so if @main is at the top level, it makes sense that you can't have 2 mains. At a different level, like scope inside an object we could always have a main per object. Now that we are having the annotation for main, we should just allow that to continue. In the end, generating a main or not, the semantics of what is written as a function, should really just act like a function. How the code is generated should not really alter the concept of the code that is written.

In this case it is just a warning but otherwise I can run this in VSCode and Metals.

package baz

object Bar {
  @main def main(): Unit = println("main Bar")
  @main def bar(): Unit = println("bar Bar")
}

What concerns me about this is I have written baz.Bar.bar and baz.Bar.main so without the annotation this seems like normal code. How that works I have no idea - I haven't looked at the generated byte code. If that isn't allowed I understand but it works - not sure why the bar function is lifted so the compiler sees the object baz.Bar and then the function baz.Bar.bar becomes baz.bar so then there is a warning. A child or beginner is unlikely to understand the file system case insensitive issue.

The following example works perfectly fine. Maybe I wasn't clear. My objection was that I couldn't have 2 main with the same signature inside different objects in the same package - I can rewrite those as a normal mains and have as many as I want but then I can't take advantage of the @main functionality.

object Foo {
  @main def main(args: String*): Unit = println("Foo")
}

Perhaps I should have put my first example that works - but with the warning. I even get like run lenses so I can run them all.

package baz

package foo {
  object Foo {
    @main def main(): Unit = println("Foo")
  }
}

object Bar {
  @main def main(): Unit = println("main Bar")
  @main def bar(): Unit = println("bar Bar")
}

The 2 mains are ok because they are in different packages. That was a modification from my original try with 2 objects with mains in the same package that didn't convert directly across from actual code in the wild.

I am unclear on the compatibility issue of the generated mains unless it is tool or TASTY related.

[tgodzik]

I imagine this could be a problem since naming is difficult and a lot of people will just do @main def main =... everywhere 😅

Would it be possible to automatically resolve such conflicts? I see two options:

• if we have the same named methods with @main annotation then add some synthetic number to the name?
• or if leave the second method inside it's current scope, generate the object inside the current object where the method is defined

This should be largely compatible, since currently this is an error, but I am not sure if it's doable?

[bjornregnell]

Adding trailing numbers 1.. to disambiguate sounds like a simple and useful enhancement. (Kind of the same idea as when scala-cli and the sbt shell when you run and there are multiple mains and you get numbers...). Nice if it "Just Works ^TM". I think it would be nice to get a warning, so that you know that ambiguous mains have been renamed.