This runs clang-format on the few files in llvm-objcopy that aren't fully formatted. It also fixes some tablegen files -- clang-format is less robust on tablegen, but the change here seems ok.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It is subjective but it seems to me that clang-format is making bad decisions for .td files. Many people don't format .td files (various lib/Target/*/*.td and include/clang/Driver/Options.td)
Formatting C++ files is fine but it seems that we run into some discrepancy between clang-format versions. Formatting with latest clang-format is probably fine.
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
210–213 | I suspect the difference is due to changed heuristics of clang-format (of different versions). | |
490 | Pre-merge checks may suggest that this is due to different versions of clang-format. I wonder whether we want to format the block. |
No issue in principle with this, but we do need to figure out the canonical version of clang-format we want to use for this if we are going to do it. I have no personal opinion on it, but suspect my installed clang-format version is out-of-date, and that if I were to do the same thing you did I'd get different results.
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
210–213 | Actually, I suspect it just wasn't formatted before - the "invalid argument for..." string below in the original is over the 80 character limit. |
Reformat with clang-format-10 to avoid clang-format version skew leading to premerge clang-format warnings
The td formatting is less robust, but works well for simple CLI option files. I'm not particularly tied to the format it chooses, but I do find the options files easier to read when consistently formatted.
The other td files you mentioned are much more complex, and I've tried using clang-format on them. It totally botches them and I don't think we should bother with complex files.
Formatting C++ files is fine but it seems that we run into some discrepancy between clang-format versions. Formatting with latest clang-format is probably fine.
Yep
What does clang-format --version look like on your machine? The one on my machine seems to be updated on a rolling basis (built from trunk on a regular basis), but sudo apt install clang-format-10 is available to use a more stable version.
llvm/tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
210–213 | Yep, this is the reason why. FWIW I also tried an old version (clang-format-7) and it still formats this block. | |
490 | This is using clang-format from head (7d9518c8000bcd742b364a390bc79560f736dc96 at the time). Using clang-format-10 restores it. I agree the version of clang-format to use is an important choice. I'll revert these portions for now and punt the question for later. |
I'm primarily a Windows-based developer, so don't expect me to be sudo-ing or apt-getting anything. I actually have 3 different clang-formats installed on my machine, it looks like, partly because it comes as part of our downstream toolchain installation package. The one that appears to be used under my most frequent usage is based on clang v8, since that seems to be the one tied to our Visual Studio extension that hooks it into the IDE, but I also have two v9 versions kicking around. I update the toolchain installation maybe once or at most twice a year, and there's usually some lag between that and the current LLVM version, so I'm always likely to be a year or two out-of-date.
I suspect the difference is due to changed heuristics of clang-format (of different versions).