[External] : Re: Case-insensitive file systems and output file clashes - survey

Archie Cobbs archie.cobbs at gmail.com
Sat Feb 25 21:28:44 UTC 2023


On Thu, Feb 23, 2023 at 7:25 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> On 2/23/23 1:06 PM, Archie Cobbs wrote:
>
> On Thu, Feb 23, 2023 at 1:33 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> On 2/22/23 10:59 AM, Archie Cobbs wrote:
>>
>> On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> On 2/22/23 8:06 AM, Archie Cobbs wrote:
>>>
>>>
>>> Add a new option -Xlint:fileclash that enables checking for clashes
>>> (e.g., at the JavacFileSystemManager layer).
>>>
>>>
>>> That would likely either be a partial solution, or an expensive one for
>>> a complete solution when taking separate compilation into account.
>>>
>> I was thinking separate compilation would definitely not be supported
>> (too complicated).
>>
>> Given that assumption, would it necessarily be only a partial fix?
>>
>> Yes, it would be a partial fix, because by your own assumption, it would
>> not cover some important cases.
>>
> Well I guess I meant, would it be "partial" in some way besides the fact
> that separate compilations are not taken into account.
>
> Digressing a bit, I'm not sure I agree that not supporting separate
> compilations makes it partial. Isn't a "compilation" the extent of the unit
> of work that a compiler is being asked to do? Asking it to solve problems
> that span multiple compilations seems out of scope. Or maybe I'm
> misunderstanding what you mean by "compilation".
>
> Compiling against precompiled class files is expecting javac to solve a
> problem spanning multiple compilations. :-)
>
> That being said, I agree it is a reasonable expectation that any one
> compilation should not write the same physical file more than once, and so
> it might be reasonable to have a possibly always-on diagnostic if that
> situation is detected, perhaps even an error.  Like the (separate) zip file
> discussion, this could be handled inside a custom file manager.  The
> challenge may be in specifying the behavior correctly, and not
> over-promising in the command-line help or man page. But if you stick to
> something like the following in the man page, you may be OK:
>
>    An error will be reported if any file is written more than once during
> a compilation. This may occur in the following situations:
> list-of-known-situations
>
I've put together a draft PR demonstrating this idea:
https://github.com/openjdk/jdk/pull/12754

It wasn't really feasible to NOT do this within the existing
JavacFileManager/BaseFileManager framework. But the changes are fairly well
contained and it works for all three output file types: class files, source
files, and native header files.

I hid this behind a new "extended" javac flag --detect-output-file-clashes
instead of adding it as a new lint option... somehow it didn't really seem
like a "lint" thing.

Please let me know what you think.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230225/ce06f71a/attachment.htm>


More information about the compiler-dev mailing list