This is an archive of the discontinued LLVM Phabricator instance.

[NFC] Run clang-format on llvm-objcopy.
Needs ReviewPublic

Authored by rupprecht on Jul 1 2020, 9:16 AM.

Details

Summary

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.

Diff Detail

Event Timeline

rupprecht created this revision.Jul 1 2020, 9:16 AM

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.

MyDeveloperDay added inline comments.
llvm/tools/llvm-objcopy/CopyConfig.cpp
490

I do believe there were some changes made recently in this area @krasimir, @Typz might like to comment

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.

rupprecht updated this revision to Diff 275772.Jul 6 2020, 11:15 AM
rupprecht marked 6 inline comments as done.

Reformat with clang-format-10 to avoid clang-format version skew leading to premerge clang-format warnings

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)

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

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.

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.

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)

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

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.

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.

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.