Bad error for macro code with scala_library #366
Comments
|
Yeah. We can look for code absent and if we hit that it must be due to a macro. Would be great to just give that error. |
|
I got a similar error when a dependency for a scala macro was missing, very hard to track down where it occured. In general, scala macros can fail for whatever reason, and bazel need to be able to catch such errors. |
|
In this case I guess scio needs to have a macro_library dependency on magnolia. This tool: https://github.com/johnynek/bazel-deps solves this problem by using scala_import (a function defined in this repo) in order to make sure scala macros are on the compilation class path. We could possibly detect this error due to where the exception is thrown and give a better error message, but we can’t change the dependencies in bazel: they are statically defined in the BUILD files. The best we could do is make a tool to automatically generate builds. |
|
I was able to solve this particular problem. But what I want to have fixed here is that bazel does not report where (in what source or BUILD file) the error occurs, making troubleshooting harder. I don't expect bazel to magically solve the problem for me, just point out where the problem occured. |
|
this isn't bazel, this is scalac. We are invoking scalac and it is throwing the |
|
@johnynek are you sure?
We’re running scalac ourselves so I think we can catch the error, inspect
it and rethrow with a clearer message. Wdyt?
…On Thu, 24 Jan 2019 at 12:08 P. Oscar Boykin ***@***.***> wrote:
this isn't bazel, this is scalac. We are invoking scalac and it is
throwing the NoClassDefFoundError. Bazel is something like a very fancy
make. There is no way bazel can solve the issue. We need the underlying
tool, in this case scalac, or another tool to compile scala, to point out
more information.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#366 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABUIF2S1pD9HSDFxsFihRrKnEcgPjRh4ks5vGeh6gaJpZM4RCVWF>
.
|
|
@ittaiz as I mentioned here: #366 (comment) yes we could do that, but he replied that we wanted to know what source we are in, but we can’t get that from the generic error thrown. Bazel already reports which build target fails. We can make it a little prettier but a huge improvement that I can see without scalac improving. |
|
No, it does not for me. At least not when running |
|
@mikaelstaldal do you recall how you fixed this issue? I've just run into it myself.. |
|
Very high level- you probably have a target (internal or external) which has a macro and is defined as a scala_library. |
|
Using |
|
Hey, folks. We've published a proposal to port some of the features from lucidsoftware/rules_scala, an alternative Scala ruleset that we maintain. Automatically detect improperly declared macro targets is one of them. Here's a link to the relevant proposal section that details specifically what we'd like to do, and a link to an issue we're using to track the broader effort: The tracking issue for this effort Are folks on board with our approach to solving this issue? We were hoping to take on this task in the near future. |
This should fail since the user should use
scala_macro_librarybut we should probably not crash the worker since it makes it very hard to understand what's happening on CI.Additionally maybe we should suggest to use
scala_macro_libraryThe text was updated successfully, but these errors were encountered: