Detect when resolve needs ModuleRef when likely cyclic references
#3878
Conversation
| } | ||
|
|
||
| if (seenModules.contains(cls)) { | ||
| Left(s"Cyclic module reference detected: ${cls.getName}, it's required to wrap it in ModuleRef. See documentation: https://mill-build.org/mill/0.12.1/fundamentals/modules.html#_abstract_modules_references") |
There was a problem hiding this comment.
It would be better if this link used the MILL_VERSION or I could not give the link. WDYT?
There was a problem hiding this comment.
Ideally, the full link should be injected and generated in build.sc, since page refactoring happens now and then, and we could feed it to our link-checker when generating the docs.
There was a problem hiding this comment.
I'd say let's just leave out the documentation link for now; we don't really have this convention in other error messages, and I feel like it would need a bit more thought to do properly (ensuring it's the right version, ensuring we don't have broken links, etc.)
myyk
changed the title
resolve needs ModuleRef when likely cyclic references
| test("moduleRefCycle") { | ||
| val check = new Checker(TestGraphs.ModuleRefCycle) | ||
| test - check( | ||
| "__", | ||
| Right(Set(_.foo)) | ||
| ) | ||
| } |
There was a problem hiding this comment.
Let's also add a few test cases for non-transitive resolves, both by normal wildcard foo.bar._ or foo.bar._.qux, as well as no-wildcard-at-all foo.bar.qux. In these cases, we should raise an error if we detect a cycle. That would keep the behavior consistent with the transitive case even if there isn't a risk of stackoverflow.
This completes #3715 with all the cycle cases I could think of.
It also touches
resolveDirectChildrenwhere I made some changes that I would help with readability. I thought I was going to need to build on those but didn't. These can be reverted if it's unwanted.