Fix package-info.java identification on Windows

[Stephan202]

A colleague using Windows reported the issue discussed in #1652, even though we use (a fork of) Error Prone 2.7.1, which contains a fix for said issue.

The problem appears to be that UnnecessarilyFullyQualified looks for a forward slash in compilationUnitTree.getSourceFile().getName(), though FileObject#getName() says:

    /**
     * Returns a user-friendly name for this file object.  The exact
     * value returned is not specified but implementations should take
     * care to preserve names as given by the user.  For example, if
     * the user writes the filename {@code "BobsApp\Test.java"} on
     * the command line, this method should return {@code
     * "BobsApp\Test.java"} whereas the {@linkplain #toUri toUri}
     * method might return {@code
     * file:///C:/Documents%20and%20Settings/UncleBob/BobsApp/Test.java}.
     *
     * @return a user-friendly name
     */

I found a similar bit of code in the PackageInfo check. This change replaces the forward slash with File.separatorChar. An alternative (presumably slightly less performant) fix is to rely on FileObject#toUri instead. Let me know if you prefer that approach.

I'll update our fork with this change and ask my colleague to test the fix.

[Stephan202]

Okay, so this change breaks the "JDK 16 on windows-latest" build:

2021-06-21T19:14:16.7280931Z positive(com.google.errorprone.bugpatterns.PackageInfoTest)  Time elapsed: 0.001 sec  <<< FAILURE!
2021-06-21T19:14:16.7282420Z Did not see an error on line 3 matching . There were no errors.
2021-06-21T19:14:16.7392132Z expected to be true
2021-06-21T19:14:16.8982839Z 	at com.google.errorprone.DiagnosticTestHelper.assertHasDiagnosticOnAllMatchingLines(DiagnosticTestHelper.java:327)
2021-06-21T19:14:17.1092494Z 	at com.google.errorprone.CompilationTestHelper.doTest(CompilationTestHelper.java:324)
2021-06-21T19:14:17.2526784Z 	at com.google.errorprone.bugpatterns.PackageInfoTest.positive(PackageInfoTest.java:38)

And:

2021-06-21T19:15:30.3709144Z packageInfo(com.google.errorprone.bugpatterns.UnnecessarilyFullyQualifiedTest)  Time elapsed: 0.021 sec  <<< FAILURE!
2021-06-21T19:15:30.6372347Z java.lang.AssertionError: 
2021-06-21T19:15:30.6378347Z Saw unexpected error on line 1. All errors:
2021-06-21T19:15:30.6457319Z /b/package-info.java:1: warning: [UnnecessarilyFullyQualified] This fully qualified name is unambiguous to the compiler if imported.
2021-06-21T19:15:30.6559011Z @a.A
2021-06-21T19:15:30.6559811Z   ^
2021-06-21T19:15:30.8401668Z     (see https://errorprone.info/bugpattern/UnnecessarilyFullyQualified)
2021-06-21T19:15:31.0392155Z   Did you mean '@A'?
2021-06-21T19:15:31.1010948Z 	at org.junit.Assert.fail(Assert.java:89)
2021-06-21T19:15:31.1074357Z 	at com.google.errorprone.DiagnosticTestHelper.assertHasDiagnosticOnAllMatchingLines(DiagnosticTestHelper.java:348)
2021-06-21T19:15:31.1083332Z 	at com.google.errorprone.CompilationTestHelper.doTest(CompilationTestHelper.java:324)
2021-06-21T19:15:31.1087501Z 	at com.google.errorprone.bugpatterns.UnnecessarilyFullyQualifiedTest.packageInfo(UnnecessarilyFullyQualifiedTest.java:163)
2021-06-21T19:15:31.1090136Z 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2021-06-21T19:15:31.1092202Z 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
2021-06-21T19:15:31.1099863Z 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
2021-06-21T19:15:31.1102930Z 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
2021-06-21T19:15:31.1108932Z 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
2021-06-21T19:15:31.1116178Z 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
2021-06-21T19:15:31.1141164Z 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
2021-06-21T19:15:31.1152902Z 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
2021-06-21T19:15:31.1154562Z 	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
2021-06-21T19:15:31.1156423Z 	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
2021-06-21T19:15:31.1164589Z 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
2021-06-21T19:15:31.1166789Z 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
2021-06-21T19:15:31.1168511Z 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
2021-06-21T19:15:31.1169904Z 	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
2021-06-21T19:15:31.1171631Z 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
2021-06-21T19:15:31.1174605Z 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
2021-06-21T19:15:31.1176541Z 	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
2021-06-21T19:15:31.1177678Z 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
2021-06-21T19:15:31.1178913Z 	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
2021-06-21T19:15:31.1180067Z 	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
2021-06-21T19:15:31.1181613Z 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
2021-06-21T19:15:31.1183570Z 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
2021-06-21T19:15:31.1185593Z 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
2021-06-21T19:15:31.1187458Z 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
2021-06-21T19:15:31.1190017Z 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
2021-06-21T19:15:31.1192758Z 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
2021-06-21T19:15:31.1194744Z 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
2021-06-21T19:15:31.1195707Z 

This might be due to the use of literal forward slashes in these tests (a, b). That could perhaps be fixed by using File.separatorChar also in these tests, but that feels wrong. More realistic would be to add proper support for Windows separators to CompilationTestHelper, but before I investigate that I'd be interested to hear whether there's interest in such a contribution.

Alternatively we could rely on FileObject#toUri after all.

[Stephan202]

My colleague confirms that the (initial) fix works. ✔️

However, I had another look with a fresh head and noticed that other checks use ASTHelpers#getFileName, which does rely on FileObject#toUri under the hood. Since using that method should also fix the Windows tests I've added another commit with this alternative solution.

[PhilippWendler]

Seems this would fix #2164.

[Stephan202]

@PhilippWendler indeed! Seems I forgot about that issue; tnx for linking :)

[Stephan202]

My colleague confirmed that the latest version of this PR also resolves the issue ✔️.

With that I think this PR is ready for review.