-
-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storing module reference in module causes resolve
to stack overflow (500USD Bounty)
#3715
Comments
Thanks for the report. This is expected but not ideal. The way to work around this is to wrap the reference in a ModuleRef, and we should try to detect these infinite recursions and provide a proper error message suggesting that |
The proper way to refer to already existing modules is to use import mill._, scalalib._
trait CommonModule extends ScalaModule {
def scalaVersion = "2.13.12"
def m1 = ModuleRef(mym1)
def m2 = ModuleRef(mym2)
}
object mym1 extends M1
trait M1 extends CommonModule
object mym2 extends M2
trait M2 extends CommonModule {
override def moduleDeps = super.moduleDeps ++ Agg(m1())
} @lihaoyi We already try to detect cycles in |
Added a 500USD bounty if anyone wants to dig into this |
resolve
to stack overflowresolve
to stack overflow (500USD Bounty)
From the maintainer Li Haoyi: I'm putting a 500USD bounty on this issue, payable by bank transfer on a merged PR implementing this.
The task is to appropriately detect module cycles during task resolution time, report a nice user-friendly error, and direct the user towards use of
ModuleRef
to fix the issue. This should be covered by unit tests, and we should verify that the module cycles in the code sample below gets properly recognized and handled.I'm trying to work out a pattern that would allow the consumer of a foreign module swap out dependencies of modules. Given the following module definition:
One can then define another
build.sc
, import the above, instantiate newM1
andM2
(for example with new Scala versions), and then have the newly instantiatedM2
depend onM1
:However this breaks
resolve
with a stack overflow error:After experimenting around a bit, it seems like the
def m1
anddef m2
module references are somehow picked up as submodules and thus resulted in an infinite loop. Wrapping the module references inSome(..)
works just ok, however it's quite cumbersome to write and feels hacky. Can this be fixed somehow?The text was updated successfully, but these errors were encountered: