Rework extensible enums

[dnakamura]

Currently, the way extensible enum files are named, requires having

my_project/compiler/Foo.enum:

#include "path_to_omr/compiler/Foo.enum"

SOME_ENUM_VAL
OTHER_ENUM_VAL
...

However, this approach breaks if the path to omr sources ever changes. Instead this PR restructures
extensible enums to work the same way as extensible classes. ie

my_project/compiler/Foo.enum:

#include "compiler/OMRFoo.enum"
...

[Leonardo2718]

@genie-omr build all

[Leonardo2718]

Looks pretty good!

Other extensible enums in the compiler use .hpp as extension, not .enum. Can you change the names of the new files so they match that convention?

[charliegracie]

is this correct?

[charliegracie]

again I am wondering why the initial copyright date was changed?

[dnakamura]

git didnt really track the changes properly. DataFlowAnalysis,enum was renamed to OMRDataFlowAnalysis.enum, and a new file was created with the old name. I was hoping that by keeping the rename in one commit, and the creation of the new file in a separate commit, git would properly track the file move, but that seems to have failed

[dnakamura]

@Leonardo2718 Can you point to an instance where the enum is in a .hpp file? I'm hesitant to make that change since its not really valid as a standalone header. From what I can tell they are designed to be used like so:

SomeEnum.hpp:

enum SomeEnum{
#include "SomeEnum.enum"
};

[Leonardo2718]

@dnakamura

That usage is correct. Other examples of extensible enums that .hpp are:

• compiler/il/OMRILOpCodesEnum.hpp
• compiler/il/DataTypesEnum.hpp
• compiler/codegen/OMRRecognizedMethodsEnum.hpp
• compiler/codegen/OMRInstructionFlagEnum.hpp
• compiler/optimizer/OMRSimplifierTableEnum.hpp
• compiler/{p,z,arm,aarch64,x}/codegen/OMRInstructionKindEnum.hpp'

They're fairly easy to find by grepping for files with Enum in their name.

.hpp may not be the best extension but I think it's the most used. If we decide to change it to something else later on, it should be easy enough to change it on all the files.

[charliegracie]

Are there other *.enum files already? To be clear @dnakamura did not create the .enum files but rather just changed their names to make it easier to work with.

[Leonardo2718]

Are there other *.enum files already? To be clear @dnakamura did not create the .enum files but rather just changed their names to make it easier to work with.

The files modified in this PR are the only ones I know of that use .enum. My thinking was that since the files are being renamed to follow the pattern of other extensible enums (and classes), also changing the file extensions so they match makes sense.

That said, I do see why using .enum makes sense. If others don't see value in changing the extension, I'll accept the changes as they currently are.

[charliegracie]

ping @Leonardo2718

[Leonardo2718]

As I mentioned in #3213, I would like to see an umbrella issue open to track why these changes are needed.

The extensible enum mechanism has historically been the source of much discussion so I want to make sure we're tracking the reasons for changing their structure.

[0xdaryl]

My preference going forward is to not use .hpp file extensions for entities that are used to compose enums and static tables. The reason is they are not complete header files and can only be included in very carefully guarded circumstances (e.g., within the braces of an enum). A different file extension makes that clear.

I support the renaming to an .enum extension for the enum files and think it should proliferate throughout OMR. I also think we need a different extension for the static table files (e.g., .table or .init).

[charliegracie]

@dnakamura ping?

[dnakamura]

#3328

[dnakamura]

@charliegracie I believe opening an umbrella issue was the only outstanding request on this PR. Feel free to correct me if I am mistaken

[Leonardo2718]

LGTM 👍