'byfile' compilation policy

[Eddie Aftandilian]

The reason we use the BYFILE policy is because for Error Prone (
github.com/google/error-prone) we want to analyze a whole compilation unit
at once.  Our analyses assume that the AST being analyzed has completed
flow but has not yet been desugared.  So if you have a compilation unit
with more than one top-level class, and one of them has proceeded past
flow, then we can't analyze it.

As Liam mentioned, the SIMPLE policy should work for our use case, but we'd
be interested to hear if you have other suggestions to solve our problem.

On Thu, Apr 28, 2016 at 1:55 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Liam,
> the approach you put forward seems sensible; one alternate approach would
> be to let the entire compilation unit through until Gen if a dependency is
> encountered rather than stopping at desugar - but I assume that's what you
> said it's problematic because of cycles?
>
> A meta-question: is it still worthwhile to have separate compilation
> policies? I see that at least two of them (ATTR_ONLY and CHECK_ONLY) can
> probably be replaced by other options (i.e. -XDshouldStop) - are there
> significant use cases out there relying on either byfile or simple? Given
> that, as it has been observed, javac will need to bypass the compilation
> policy anyway to guarantee the correctness of the generated code (i.e. that
> supertypes are desugared before subtypes) - can a client really blindly
> rely on the assumption that a compilation policy does what it says on the
> tin?
>
> Maurizio
>
>
> On 28/04/16 01:50, Liam Miller-Cushon wrote:
>
>> Hi, I encountered an issue with the 'byfile' compilation policy.
>> Desugaring adds additional ordering constraints so superclasses get
>> desugared first [1]. That causes classes to be processed separately from
>> their compilation unit, and breaks the ordering specified for byfile.
>>
>> [1]
>> http://hg.openjdk.java.net/jdk9/dev/langtools/file/2aa0433e0add/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java#l1428
>>
>> Demo:
>>
>> $ cat A.java
>> class One extends Three {}
>> class Two {}
>>
>> $ cat B.java
>> class Three {}
>> class Four extends Two {}
>>
>> $ javac -XDcompilePolicy=byfile -XDverboseCompilePolicy A.java B.java
>> [attribute One]
>> [attribute Two]
>> [flow One]
>> [flow Two]
>> // desugaring One starts, but it depends on Three
>> [attribute Three]
>> [flow Three]
>> [desugar Three]
>> // resume desugaring One
>> [desugar One]
>> [desugar Two]
>> [generate code One]
>> [generate code Two]
>> // Four is compiled separately from its compilation unit
>> [attribute Four]
>> [flow Four]
>> [desugar Four]
>> [generate code Three]
>> [generate code Four]
>>
>> We're using byfile because it allows analyzing an entire compilation unit
>> after attribution and before any lowering, like 'simple' but with similar
>> performance to 'todo'. I think using simple might be fine, but I haven't
>> done any performance analysis yet.
>>
>> Changing byfile to process entire compilation units in a group and also
>> desugar supertypes first appears to be impossible, because there could be
>> cycles.
>>
>> A partial fix might be to change desugar's handling of dependencies so a
>> dependency's entire compilation unit goes through flow, before the
>> dependency is desugared. That would result in something like:
>>
>> [attribute One]
>> [attribute Two]
>> [flow One]
>> [flow Two]
>> // desugaring One starts, but it depends on Three
>> // perform attr and flow on Three and Four together
>> [attribute Three]
>> [attribute Four]
>> [flow Three]
>> [flow Four]
>> // now desugar just Three
>> [desugar Three]
>> // resume desugaring One
>> [desugar One]
>> [desugar Two]
>> [generate code One]
>> [generate code Two]
>> // Four is desugared separately from its compilation unit
>> [desugar Four]
>> [generate code Three]
>> [generate code Four]
>>
>> Does the partial fix sound worthwhile?
>>
>> Thanks,
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160428/adb6dd11/attachment.html>