-
Notifications
You must be signed in to change notification settings - Fork 745
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
UnusedVariable sometimes gives false positives for record parameters #2713
Comments
Following the fix for #1648 , I also updated to 2.10.0 and tried to remove all the BTW : |
FWIW, I still see this in errorprone 2.11.0 (and 2.13.1) |
The following tiny example also gives errors: package example;
import static org.junit.Assert.assertEquals;
import org.junit.Test;
public class TestRecord {
public record MyRecord(int foo, int bar) {}
@Test
public void record() {
var rec = new MyRecord(2, 3);
assertEquals(2, rec.foo());
assertEquals(3, rec.bar());
}
} Tested via bazel (5.1.0) with the following BUILD file: load("@rules_java//java:defs.bzl", "java_test")
java_test(
name = "TestRecord",
size = "small",
srcs = ["TestRecord.java"],
deps = ["@junit"],
javacopts = [
"-Werror",
"-XepAllDisabledChecksAsWarnings",
],
) It fails like this:
It seems like it doesn't understand that the field are indirectly used by the generated getter functions? |
We recently started adopting record classes and we can still reproduce this error with similar patterns as the ones posted above. For now, we added a public class Example {
@SuppressWarnings("unused")
private record MyRecord(int x) { }
} |
Warning suppression is not ideal as it may lead to suppression of more then originally desired. Work around google/error-prone#2713 using error-prone's annotation-based suppression mechanism. Note: using `@Keep` directly is not effective. Only `@Keep`-annotated annotation seems to work. Note 2: using this annotation isn't usually required, as parameter validation in compact constructor usually makes error-prone happy and avoids aforementioned issue. Use it only when needed.
@knutae, which Error Prone version is your sample using (I am not very familiar with Bazel)? Does it use a version < 2.10.0 because in that version the false positives for record fields were supposedly fixed (47da3af). When I tried to recreate your sample (without Bazel) I was not able to reproduce it with the latest Error Prone version. |
Looks like Bazel 5 uses Error Prone 2.9.0. So hopefully this will be fixed by upgrading to Bazel 6, which uses 2.11.0. |
Problem still happens with Bazel 6.2.0 shipping with Error Prone 2.18.0. |
This issue is still happening with error-prone 2.19.1 |
Problem still happens with Bazel 6.3.0 shipping with Error Prone 2.20.0. |
Fixes #2713 It looks like the tree emitted by the compiler is incomplete for the canonical constructor of a record, which is why the parameters were erroneously flagged as unused. Apparently this only affected `private` record classes because for them the implicit canonical constructor is `private` as well, and the `UnusedVariable` check treats parameters of `private` methods and constructors differently. #2713 (comment) showed an example where this also affected record fields, however I was unable to reproduce that. Maybe they were using an older Error Prone version which does not include 47da3af, their sample code is incomplete, or my test setup was incorrect. Edit: It looks like they were using an older Error Prone version, see #2713 (comment). Fixes #3837 FUTURE_COPYBARA_INTEGRATE_REVIEW=#3837 from Marcono1234:record-unused-param-false-positives 4535778 PiperOrigin-RevId: 557194050
Fixes #2713 It looks like the tree emitted by the compiler is incomplete for the canonical constructor of a record, which is why the parameters were erroneously flagged as unused. Apparently this only affected `private` record classes because for them the implicit canonical constructor is `private` as well, and the `UnusedVariable` check treats parameters of `private` methods and constructors differently. #2713 (comment) showed an example where this also affected record fields, however I was unable to reproduce that. Maybe they were using an older Error Prone version which does not include 47da3af, their sample code is incomplete, or my test setup was incorrect. Edit: It looks like they were using an older Error Prone version, see #2713 (comment). Fixes #3837 FUTURE_COPYBARA_INTEGRATE_REVIEW=#3837 from Marcono1234:record-unused-param-false-positives 4535778 PiperOrigin-RevId: 557197001
Fixes #2713 It looks like the tree emitted by the compiler is incomplete for the canonical constructor of a record, which is why the parameters were erroneously flagged as unused. Apparently this only affected `private` record classes because for them the implicit canonical constructor is `private` as well, and the `UnusedVariable` check treats parameters of `private` methods and constructors differently. #2713 (comment) showed an example where this also affected record fields, however I was unable to reproduce that. Maybe they were using an older Error Prone version which does not include 47da3af, their sample code is incomplete, or my test setup was incorrect. Edit: It looks like they were using an older Error Prone version, see #2713 (comment). Fixes #3837 FUTURE_COPYBARA_INTEGRATE_REVIEW=#3837 from Marcono1234:record-unused-param-false-positives 4535778 PiperOrigin-RevId: 557197001
I'm still getting this as well for Pretty simple to reproduce class ErrorProneBug {
private record Stuff(boolean stuff) {
}
public static void main(String[] args) {
new Stuff(true).stuff();
}
}
|
The fix was merged last week, 2.21 is 3 weeks old, so this is expected. |
Sorry I for some reason got confused on the timing and thought errorprone just got released. |
Using error-prone 2.10.0.
Here's a trivial example of a record where I get a warning that the
x
value is never being used, even though there are public methods that access it both directly and via its getter.I don't know the exact conditions that trigger this, but for example if I make the record itself
public
the warning goes away.The text was updated successfully, but these errors were encountered: