"CompileCommand" is used both as a enum type (compilerOracle.hpp), and a global variable (compiler_globals.hpp).
This makes very awkward to the enum type -- we are forced to use 'enum CompileCommand' in the source code whenever a type is needed:
This simple c++ file illustrates the problem:
================
enum class CompileCommand { a, b, c };
void foo(CompileCommand x) {}
char* CompileCommand; // can no longer use "CompileCommand" as a type
void good(enum CompileCommand x) {}
void bad(CompileCommand x) {}
==================
$ g++ -c ~/enum.cpp
/home/iklam/enum.cpp:5:6: error: variable or field ?bad? declared void
5 | void bad(CompileCommand x) {}
Proposed fix:
The fix is to rename the enum type to CompileCommandEnum.
This also makes it possible to forward-declare the CompileCommandEnum without including compilerOracle.hpp. This improves HotSpot build time by reducing the number of .o files that includes compilerOracle.hpp from 456 to 16.
This makes very awkward to the enum type -- we are forced to use 'enum CompileCommand' in the source code whenever a type is needed:
This simple c++ file illustrates the problem:
================
enum class CompileCommand { a, b, c };
void foo(CompileCommand x) {}
char* CompileCommand; // can no longer use "CompileCommand" as a type
void good(enum CompileCommand x) {}
void bad(CompileCommand x) {}
==================
$ g++ -c ~/enum.cpp
/home/iklam/enum.cpp:5:6: error: variable or field ?bad? declared void
5 | void bad(CompileCommand x) {}
Proposed fix:
The fix is to rename the enum type to CompileCommandEnum.
This also makes it possible to forward-declare the CompileCommandEnum without including compilerOracle.hpp. This improves HotSpot build time by reducing the number of .o files that includes compilerOracle.hpp from 456 to 16.