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
Defer "pure expression .. in statement position" warnings until refchecks. #8995
Conversation
Conserve unchanged blocks and templates in the output and avoid temporary lists.
/rebuild |
fa9d891
to
0bb09c6
Compare
…ecks. This allows a macro to transform code that used to warn into something that does not.
0bb09c6
to
58407ea
Compare
The macro use case corresponds to the linting mode. It's impossible to know in advance, for a given macro, whether before or after expansion should look "clean." The "pure expr" check is narrow enough that post-expansion is clearly an error; but if the user writes
it depends on The unused warnings are emitted after typer only because imports are tracked then.
|
My bias is removing false warnings (especially ones that users can't suppress), so I'm not overly worried about the subset of macros that transform warnable input into non-warnable output trees. But, with this warning in refchecks, it would possible to hitch it to the An example of such a macro where we'd lose the warning is
A macro implementation that uses a warning
|
|
I appreciate the discussion! This is an aspect of the macro system that didn't have any up-front design so its hard to figure out the answers that balance strictness of warnings vs false positives and have good defaults that avoid the need for users to tweak compiler options. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is likely to be an improvement for most use cases, so let's book it, even if we're lacking a principled approach.
For some reason, in the recent releases "a pure expression does nothing in statement position" has gotten more accurate. Maybe because it moved to RefCheck in scala#8995? Regardless, it's sometimes tricky to write `build.sbt` because often I would need to invoke multiple tasks such as `compile.value` and `copyResources.value` without using the return value, and it would cause "a pure expression does nothing in statement position" error. As a workaround I propose `Predef.unit(a: Any): Unit = ()`, which forces the evaluation but discards it and returns the unit value, which the compiler seems to be happy with.
For some reason, in the recent releases "a pure expression does nothing in statement position" has gotten more accurate. Maybe because it moved to RefCheck in scala#8995? Regardless, it's sometimes tricky to write `build.sbt` because often I would need to invoke multiple tasks such as `compile.value` and `copyResources.value` without using the return value, and it would cause "a pure expression does nothing in statement position" error. As a workaround I propose `Predef.unit(a: Any): Unit = ()`, which forces the evaluation but discards it and returns the unit value, which the compiler seems to be happy with.
This allows a macro to transform code that used to warn into something that
does not.