Hi all, Currently we have several separate measures in place to enforce some code conventions in HotSpot. We have an include sorting tool and a tool that does a regex check to see if the string NULL appears in any HotSpot source files, and lastly a rather convoluted system within some HotSpot headers as well to restrict calling of some methods that we don't want to be used unless explicit permission is given.
The problem in my eyes is that this is not the cleanest way to achieve this goal, the include sorting tool and the NULL check don't actually parse C++ source code and instead try to find specific strings in the source. But the biggest offender would not be these two, but rather the restriction system for forbidden methods currently in place. It relies on having internal knowledge of system headers and is somewhat unwieldy to use given the interface, and has a lot of infrastructure that had to be put in place to deal with nasty compiler bugs, and interferes with actual system headers that we include. Given these downsides, it would seem like getting a proper tool to enforce code guidelines would be an improvement. I initially attempted to write a HotSpot specific C++17 Lexer and Parser to analyze HotSpot source code and enforce these rules, and also experimented with the clang LibTooling libraries to check HotSpot code, but was recently made aware that clang-tidy has the facilities that we desire. Replacing the existing restriction system with clang-tidy would solve all the issues listed above, but at the small downside of requiring clang-tidy as a dependency. A custom in tree tool written in Java like the C++17 Lexer and Parser I mentioned above eliminates this dependency, but we'd have to maintain the tool in sync with which C++ version we're using, which is not preferable, so clang-tidy seems the better choice. Besides restricting what can be called, clang-tidy can also do many other things that we might desire, such as not allowing NULL to be used in source code. Given the benefits, is the dependency on clang-tidy something that is acceptable? To my knowledge it does not require the entirety of LLVM to function, which would be a deal breaker if it did. I'd like to get consensus on this to see whether clang-tidy is fine to use as a tool for HotSpot. I imagine it does not have to be a hard dependency (If the tool is not found, the build continues without it) and its main use would be in the GitHub runners to enforce code style. best regards, Julian Also, could I also ask what the rules for include order are in HotSpot? We could also use clang-format for that, but I'd need to know what the desired include order is.
