Replies: 1 comment 3 replies
-
Following your idea but without looking into the source file, there is a high chance of producing false warnings. Although equally named files could contain perfectly unambiguous content. The issue itself is also a runtime problem, not a compile-time problem. So to provide any useful insights, a full classpath scan would be required, which is an expensive operation. Nothing we would want to run before each run. Nevertheless, such tooling is possible and probably already exists. It would be best provided as some kind of diagnostics task to be used if there were run issues. I'm moving this into discussions for now. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This ticket arose out of scalatest/scalatest#2354.
I've this repo with the following structure:
Both
package.scala
are in the packagegraph
. While running tests, thesrc/package.scala
is chosen by the classloader, causing aNoSuchMethodError
(the method exists in thetest/src/package.scala
, and code compiles fine). Luckily, I was able to create a simple reproducer, and the folks at scalatest were kind enough to look into the issue, but in a larger project, this sort of inadvertent problems could be almost impossible to track down, especially because Scala classes and objects don’t have to follow the directory structure of their packages.It was mentioned in the scalatest ticket that:
Hence, this ticket.
It'll be extremely helpful to have some sort of warning if multiple classes with the same qualified name exist, as well as a message showing which one is loaded. FWIW, there appears to exist a SBT plugin for this purpose.
Beta Was this translation helpful? Give feedback.
All reactions