Add a setting to disable --Wno-error=unknown with clang-format

[sean-mcmanus]

Follow up to https://github.com/microsoft/vscode-cpptools/issues/10072

Related to this would be surfacing the errors (other than a generic failure)...that could be tracked separately later if necessary.

[saierd]

@sean-mcmanus #10072 Makes it impossible to use older versions (< 12) of clang-format, which don't have --Wno-error=unknown yet.

The default version of the clang-format package in Ubuntu <= 20.04 cannot handle this option. Additionally, older versions of clang-format are still widely in use in my experience due to how formatting changes often between different versions.

I would therefore argue that the change from #10072 should not be published without an accompanying solution to this issue.

[sean-mcmanus]

@saierd We'll add a clang-format version check, since we need that check to work with clang-format older than 9 anyway and potentially could use it for other stuff later. Does that sound sufficient? See https://github.com/microsoft/vscode-cpptools/issues/10178

[saierd]

Sure, that's even better than having to disable the flag manually.

[sean-mcmanus]

@saierd The clang-format version checking got added with 1.13.5 (pre-release, release candidate): https://github.com/microsoft/vscode-cpptools/releases/tag/v1.13.5 . Let us know if you hit any issue with that.

[NepEgor]

Hi @sean-mcmanus I'm using current release (1.13.9) cpptools and I run into this issue with clang-format-11 I have also tried current pre-release (1.14.2) with the same outcome Could you please advise if it's me doing something wrong or this feature is not implemented yet?

[sean-mcmanus]

@NepEgor The issue is fixed for me -- we launch clang-format with the --version to get the version. It's possible that is failing for some unexpected reason. If you set C_Cpp.loggingLevel to the hidden value of "7" temporarily and then do the formatting you can see the raw command line that we run in the C/C++ logging. For clang-format 11 it should not show "--Wno-error=unknown". If you see that, then try adding "--version" to the path to the clang-format it is running to see if the result matches clang-format version <maniVersionNumber>.<restOfVersion> or not.

[NepEgor]

I have explored around for a bit more and found out that cpptools seem to not work with clang-format symlinks. I can invoke clang-format through a symling from cli without a problem. And changing path for cpptools to either of actual clang-formats works (The topic flag is not present in clang-format-11 call). So perhaps I should open a new issue (if there are no such issues) for this particular problem :D

lrwxrwxrwx 1 root root /usr/bin/clang-format -> /usr/bin/clang-format-12
lrwxrwxrwx 1 root root /usr/bin/clang-format-11 -> ../lib/llvm-11/bin/clang-format
lrwxrwxrwx 1 root root /usr/bin/clang-format-12 -> ../lib/llvm-12/bin/clang-format

[sean-mcmanus]

@NepEgor Yeah, can you open a new issue that describes the problem with clang-format symlinks? The /usr/bin/clang-format is usually a symlink, so I'm not aware of any issue with clang-format symlinks.

[saierd]

@sean-mcmanus I had the same problem again and could find another condition for this to occur: VS Code has to be connected remotely via SSH, otherwise a symlink clang-format works as expected. I opened #12298 as requested.