-
Notifications
You must be signed in to change notification settings - Fork 42
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
[BUG] Resolution error with proofs plugin when using certain types from other packages. #950
Comments
@raulraja I'd be happy to look at this one if you have some suggestion for where I might look. |
Hi @Sintrastes , I believe your proposed fix can be applied here https://github.com/arrow-kt/arrow-meta/blob/main/plugins/proofs/proofs-plugin/src/main/kotlin/arrow/meta/plugins/proofs/phases/quotes/GenerateGivenSupportingFunctions.kt#L76-L103 |
@raulraja Thanks for the suggestion. Unfortunately, it looks like this is not as easy of a fix as I thought. This may still be part of the problem, but it actually looks like when the plugin tries to look up given instances for a generic class that is not defined in the current package, it can't actually find those instances. I have a fork here where I've added a test to try and catch this issue -- and there I am actually getting this error before the unresolved reference error I was getting before:
|
Although, for what it's worth, whenever I try to use |
That second error |
Describe the bug
When using
@Given
annotations with the arrow proofs compiler plugin, and using an@Given
context that references certain classes in a different package from where the@Given
annotations are being used, sometimes the generated code will have unresolved reference errors.To Reproduce
Compile a project with the following two files:
After compiling a project with these two files, the generated code for the
fmapPlusTwo
method looks like this:with an unresolved reference error for
Functor
.Expected behavior
The above examples should compile successfully.
Environment (please complete the following information):
Additional context
It's not entirely clear to me yet exactly when this issue occurs. This didn't seem to be an issue for another example where the type I imported from a different module was just a simple (i.e. not generic) type -- so perhaps the issue arises with generics.
I believe this issue could be solved by making sure to always use fully qualified names for all generated code.
The text was updated successfully, but these errors were encountered: