attributing files with syntax errors

[Liam Miller-Cushon]

I spent some time yesterday being surprised by the behaviour of
-XDcompilePolicy=todo:

$ cat Test.java
import no.such.pkg.MissingSymbol;

class Test {{
  new MissingSymbol();
}}

$ javac -XDshouldStopPolicyIfError=INIT -XDcompilePolicy=todo Test.java
Test.java:1: error: package no.such.pkg does not exist
Test.java:4: error: cannot find symbol

$ javac -XDshouldStopPolicyIfError=ATTR -XDcompilePolicy=todo Test.java
Test.java:1: error: package no.such.pkg does not exist
Test.java:4: error: cannot find symbol

$ javac -XDshouldStopPolicyIfError=INIT -XDcompilePolicy=byfile Test.java
Test.java:1: error: package no.such.pkg does not exist

$ javac -XDshouldStopPolicyIfError=ATTR -XDcompilePolicy=byfile Test.java
Test.java:1: error: package no.such.pkg does not exist
Test.java:4: error: cannot find symbol

In the first compilation, the 'cannot find symbol' error is emitted despite
-XDshouldStopPolicyIfError=INIT. I expected the output to look like it does
with a byfile policy (the third example).

This appears to be a known issue: "in bytodo mode, javac will still
attribute files after syntax errors. Changing that behavior may surprise
existing users, so for now, we work around it." [1] This seems to affect
all policies except byfile.

Is there any chance this can be fixed? It's a simple patch, which I'd be
happy to contribute. Most of the work is fixing up existing tests that
produce different diagnostics after the fix.

If the fix is still too risky, is it worth considering changing byfile to
match the other policies? I think the difference between policies is more
surprising than fixing the bug would be. If that isn't an option either,
it'd be nice to at least create a tracking bug and document the issue
somewhere more discoverable.

Thanks,
Liam

[1]
http://hg.openjdk.java.net/jdk9/dev/langtools/file/eaab8a16dcfb/test/tools/javac/policy/test3/Test.java#l98
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150820/34da0fb9/attachment.html>