On Sun, 23 Mar 2025 21:14:47 GMT, Doug Simon <dnsi...@openjdk.org> wrote:
> This PR adds `bin/sort_includes.py`, a python3 script to check that blocks of > include statements in C++ files are sorted alphabetically and that there's at > least one blank line between user and sys includes (as per the [style > guide](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#source-files)). > This script can also update files with unsorted includes. The second commit > in this PR shows the result of running: > > python3 ./bin/sort_includes.py ./src/hotspot > > To prevent an include being reordered, put at least one non-space character > after the closing `"` or `>`. See `src/hotspot/share/adlc/archDesc.cpp` for > an example. > > Assuming this PR is integrated, jcheck could be updated to use it to ensure > include statements remain sorted. Thanks for all the comments so far. First thing is that my tool does nothing about re-ordering block of conditional includes vs unconditional includes. I briefly looked into that but it gets very complicated, very quickly. That kind of re-ordering will have to continue to be done manually or someone is going to have to invest significant time in enhancing/replacing the tool I wrote. Also, the tool tries to not change the number of lines in the original file. It should only add blank lines where necessary to separate user includes from sys includes. This explains some of the extra blank lines. For example, if the original was: 1: #include "a.h" 2: 3: #include "b.h" 4: 5: #include <c.h> 6: 7: #include <d.h> the output is: 1: #include "a.h" 2: #include "b.h" 3: 4: #include <c.h> 5: #include <d.h> 6: 7: Once again, I'd prefer to keep the tool simple and focused on the main task of ordering includes. Cleaning up extraneous blank lines can be done manually after running the tool. I'm currently working on converting `sort_includes.py` to `SortIncludes.java`. Once done, I'll open a second PR and limit changes to the C++ files I'm comfortable with changing and testing (namely in JVMCI directories). I will include a jtreg test to ensure these changes do not regress. Follow up issues can then be opened for working on the remaining C++ files. The main point of this initial PR is to show that such a tool can be useful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24180#issuecomment-2752572125
