acyclic.pkg declaration doesn't persist between compilation runs

[gshakhn]

Thanks for creating the plugin. Starting a fresh project and want to have clean code. :)

I'm testing out the plugin to make sure I've configured it correctly. It doesn't seem to detect package cycles in test code, See https://github.com/gshakhn/acyclic-test for a sample project.

Running sbt test:compile doesn't cause a compilation error. If classes A and B are moved to the source directory, running sbt compile makes the compile fail as expected.

Am I missing a configuration option, or does the plugin not support test code?

[lihaoyi]

The problem here is that it can only detect cycles when everything is in the same compilation run, because the compiler only gets "given" all those files at once. With main/ and test/, they are given to the compiler in separate compilation runs, and thus the compiler doesn't remember that you said anotherpackage was acyclic when compiling main/ in order for it to fail when compiling test/. Moving the package object and acyclic.pkg declaration into test/ should make it fail too.

Not sure what the correct path forward is here. Maybe I could leave some package annotation of some sort in the package object's classfile? I've never done anything like that before. I guess you could be charitable and call it "unsupported" =P

[gshakhn]

Thanks for the quick response!

I tried moving the package object to the test directory in https://github.com/gshakhn/acyclic-test/tree/acyclic-declaration-in-test-dir, but sbt test:compile still passes. :(

Perfectly fine if it's unsupported. Just want to make sure I'm aware of the limitations. Plus documenting it here for future people who google. :)

[gshakhn]

Err, I didn't actually import acyclic.pkg in the test package object. Counted on IntelliJ to do the right thing... Sorry for the false alarm..

[lihaoyi]

Yeah intellij doesn't do the right thing due to the fact that the import is "unused". Unfortunately there's no way to tell it the import is special in any way, and there's no way to add @annotations on the file-level

[gshakhn]

Guessing this could be fixed via package object annotations instead of importing something "unused"? Waiting on https://issues.scala-lang.org/browse/SI-3600 for that.