How can I set .clang-format globally?

[snowphone]

I'm struggling with this problem for hours.

As far as I know, clangd doesn't have -style option unlike clang-format and there's no way to set my custom format in my coc.nvim + coc-clang environment (I found -fallback-style option but it is not customizable because it is a kind of presets).

So, is there any way to set a global formating option like vim-clang-format?

[sam-mccall]

it is not customizable because it is a kind of presets

I'm not sure about this: -fallback-style accepts the same options as clang-format -style which is used by vim-clang-format. It can be a string like LLVM for a preset, or a YAML document within {} - this is the same format used in .clang-format files and can customize any settings.

e.g. `clangd -fallback-style="{BasedOnStyle: LLVM, IndentWidth: 4}'" I think someone is working on making it possible to include a separate file in BasedOnStyle too, bu that hasn't landed yet.

That said, using a .clang-format file is the recommended solution and we're not likely to add more options to avoid doing that. The reason is that it's important that the style for a given project is consistent even if there are multiple contributors or if one contributor works on several projects with different styles. If this is just for personal projects that you don't share with anyone else, you can put .clang-format in your home directory etc.

[snowphone]

I tried like clangd -fallback-style={...} but it didn't work.

As you said, duplicating.clang-format per project is the easiest solution. But, in my case, I use a single convention that is not yet consistent so duplicating .clang-format wasn't an optimal solution :( That's why I wanted a "global" option.

I thought clangd doesn't have arguments for this purpose (I tried clangd --help and as far as I know there was nothing like clang-format -style=...) but some plugins --- vim-clang-format and so on --- supports it so I was wondering about overriding some features in coc-clangd. Plus, the reason why I did not use vim-clang-format is I'm a coc.nvim user and it provides an interface :Format for formatting codes, so I just wanted to keep the interface.

[ghost]

-fallback-style accepts the same options as clang-format -style

That seems not to be the case, or it's bugged, or I'm setting it incorrectly in coc-settings.json.

I tried "clangd.arguments": [ "-fallback-style='{BasedOnStyle: LLVM, IndentWidth: 8}'" ], but clangd reports: I[04:00:15.843] getStyle() failed for file /home/ave/clang-format-repro/main.cc: Invalid fallback style "'{BasedOnStyle: LLVM, IndentWidth: 8}'. Fallback is LLVM style. (also notice an unclosed "). :Format formats as default LLVM. If .clang-format is present with contents {BasedOnStyle: LLVM, IndentWidth: 8}, it still formats as default LLVM (definitely a bug?). If I use "clangd.arguments": [ "-fallback-style=WebKit" ] it formats correctly as WebKit. If .clang-format is present with contents {BasedOnStyle: LLVM, IndentWidth: 8}, it formats as LLVM with 8 spaces. This is all reproducible on:

vim version: NVIM v0.4.4
node version: v14.12.0
coc.nvim version: 0.0.79-6cb5c6cd2d
term: xterm-kitty
platform: linux
I[04:09:38.270] clangd version 10.0.1 

with corresponding LLVM tooling being version 10 (same as clangd).

So I'm either not setting it correctly, or there are 2 issues:

1. fallback style not correctly interpreted from {}
2. when 1) fails the default style is set, and when that happens .clang-format in current folder is ignored

Third issue is cosmetic -- unmatched " in log report.

[ErikReider]

I'm experiencing the same issue as @avemilia

[ErikReider]

Fixed this issue by using a .clang-format file instead. It works but it's not optimal

[kadircet]

There are two issues here, mostly inherited from clang-format itself:

• FallbackStyle cannot be a custom style definition, it has to be a predefined style.
• If FallbackStyle doesn't correspond to a predefined style, style detection fails, even in the presence of a .clang-format file.

The first issue limits users ability to define a custom "global" fallback for format style to clangd. We can extend FallbackStyle handling in clang-format to accept custom ones. That's not the case currently probably because they don't want to parse the fallback configuration string at every call(but they are happy to read it from file and parse it again ?!?). But we can overcome this by parsing it once on the caller side and taking a pre-built FallbackStyle, rather than a string one. In addition to that, we might want to have a section in Config for FallbackStyle. WDYT @sam-mccall ?

For the second issue, it seems like a straight forward fix, but it implies a change in behaviour. Maybe they've a good reason for bailing out early whenever the FallbackStyle is malformed. I'll put together a patch and try to find some clang-format reviewers to see if they got any concerns.

As for a workaround until we take some action, similar to what @ErikReider did, you can put a .clang-format file at a top level like $HOME/.clang-format (assuming source files you edit are living under $HOME/...). Then clangd will read style from that file, if it fails to find any config closer to file being edited instead.

[kadircet]

Sent out https://reviews.llvm.org/D95538 for the latter issue.

[sam-mccall]

FallbackStyle cannot be a custom style definition, it has to be a predefined style.

Right - I was mistaken about the -fallback-style behavior, sorry.

This could be fixed in clang-format, it seems a little cumbersome to use but not terrible. There was also a proposal to let -style be a file, which would interact nicely here. Seems to have stalled though.

If FallbackStyle doesn't correspond to a predefined style, style detection fails, even in the presence of a .clang-format file.

This doesn't seem like a problem. If FallbackStyle is effectively an enum, then what's the purpose of allowing an invalid value so long as you never use the feature? No other flags work that way.

[kadircet]

This doesn't seem like a problem. If FallbackStyle is effectively an enum, then what's the purpose of allowing an invalid value so long as you never use the feature? No other flags work that way.

Fair point if you treat this as a "flag", and if we are going down that path, I would suggest literally checking for that and shutting down if need be at the startup (same with other flags) rather than just logging some errors. I was treating this more like a function parameter, hence the different interpretation.

[ShellCode33]

What I did to work this around is to copy my .clang-format fallback at the root of my system. Whether I edit a file in /tmp, /etc, /whatever, it will always end up using /.clang-format. This is dirty af but it works... If you have a .clang-format further down the tree it will be used instead.

[shivanshu-semwal]

Is this fixed? I switched to this extension from https://github.com/microsoft/vscode-cpptools this one, it provides an option C_Cpp.clang_format_fallbackStyle

"C_Cpp.clang_format_fallbackStyle": "{ BasedOnStyle: LLVM, UseTab: Never, IndentWidth: 4, TabWidth: 4, BreakBeforeBraces: Attach, AllowShortIfStatementsOnASingleLine: true, IndentCaseLabels: false, ColumnLimit: 0, AccessModifierOffset: -4, AllowShortLoopsOnASingleLine: true}",

Can we have this option for clangd extension.

[fannheyward]

clangd's issue.