RFR (tedious) 8216022: Use #pragma once

[coleen.phillimore at oracle.com]

On 1/3/19 2:26 PM, Erik Österlund wrote:
>
>
> On 2019-01-03 19:39, Andrew Haley wrote:
>> On 1/3/19 3:50 PM, Erik Österlund wrote:
>>
>>> I think the value of moving to #pragma once instead of using include
>>> guards is that it is easy to mess up include guards. Admittedly, at
>>> least I tend to get them wrong quite often, and every time I get
>>> annoyed that we don't use #pragma once
>>
>>
>>> ... Might be exaggerating a bit... but still.
>>
>> Maybe. :-)
>>
>> But seriously, how often do you actually have to create a new header
>> file, or even edit the part of a header file that touched the include
>> guards? The reason this bug hasn't got much love at GCC is that over
>> there nobody (including, until today, me) could ever see the point of
>> include guards. It seems to me that they are a rather fragile way of
>> fixing a nonexistent problem.
>
> It happens quite a lot actually. For example, it looks like there are 
> currently 126 barrier set files, of which 67 are header files. I had 
> something to do with most of them. I will never forget the include 
> guard horrors when *BarrierSetAssembler was renamed.
>
> Sometimes I think the include guard horrors make us grow files too 
> large, because of that extra overhead of creating a new file. Same 
> goes for renaming or moving files that obviously have the wrong name 
> or are in the wrong directory, like memory/heap.hpp, that should 
> arguably be code/codeHeap.hpp.
>
> Not to talk about when the "vm" directory was dropped. We are still 
> living in the aftermath of that, and include guards now inconsistently 
> sometimes have the VM_ prefix and sometimes not depending on how old 
> the file is and how the author of new files since then have thought 
> about it. Did they want to blend in with the old (wrong) prefix, or 
> use the correct prefix? Or when the gc_interface/gc_implementation 
> directories were removed, making all GC files move. Ouch.

I have to admit that Erik was an instigator of this, but I've been 
cringing lately at the extra "_VM" in the include guards, and people 
asking me whether to include it or not in their new files.   Maybe? At 
any rate, I've wanted to fix them all and this seems a lot better.  I 
might experiment with the tool pointed out to change them all back to 
the correct file name if this change is too discomforting.

Plus, there have also been discussion about whether the coding standard 
should say that the end guard should have:

#endif // SAME_NAME_AS_BEGIN
or
#endif // include guard
or as Erik slipped up and wrote:
#endif // pragma once

*And* as Thomas Stuefe likes:

#ifndef FILE_NAME_

with the trailing underscore.

We can cut off this discussion by having pragma once.

There have been many new header files added lately for jdk11 and 12, and 
I don't think we're quite done, so we expect more.  Refactoring a huge 
header file like thread.hpp might be really nice to do.  So it would be 
nice to have some smaller header files added.

Thanks Erik and Andrew.
Coleen

>
>> But hey, if it's really important to you, go ahead. This issue isn't
>> something I'm prepared to go to the barricades for.
>>
>
> Okay, thanks Andrew!
>
> /Erik