C_Cpp.clang_format_style=file works incorrectly

[alexfh]

• VSCode Version: Code 1.4.0 (6276dcb0ae497766056b4c09ea75be1d76a8b679, 2016-08-04T16:49:32.489Z)
• C/C++ for Visual Studio Code extension version: 0.9.0
• OS Version: Linux x64 3.13.0-92-generic

The extension doesn't seem to apply C_Cpp.clang_format_style=file correctly. My settings.json contents:

{
    "C_Cpp.clang_format_style": "file",
    "C_Cpp.clang_format_fallbackStyle": "Visual Studio"
}

But files seem to be formatted using the "Visual Studio" style.

Steps to Reproduce:

1. Install vscode and the C/C++ extension.

2. In terminal:

   $ mkdir /tmp/vscode-clang-format
   $ echo "BasedOnStyle: LLVM" > /tmp/vscode-clang-format/.clang-format
   $ echo "void f() { int a; int b; }" > /tmp/vscode-clang-format/file.cpp
   $ clang-format -style=file /tmp/vscode-clang-format/file.cpp 
   void f() {
     int a;
     int b;
   }
   $ code /tmp/vscode-clang-format/
   

3. Open /tmp/vscode-clang-format/file.cpp

4. Change workspace settings (settings.json) to:

   {
       "C_Cpp.clang_format_style": "file",
       "C_Cpp.clang_format_fallbackStyle": "Visual Studio"
   }
   

5. Press Ctrl-Shift-I. Observe that an incorrect style is applied to the file.

6. Save the file

7. The resulting formatting is:

   $ cat /tmp/vscode-clang-format/file.cpp 
   void f()
   {
       int a;
       int b;
   }
   

Looks like the arguments supplied to clang-format in my case are:

  -style={ BasedOnStyle: LLVM, UseTab: Never, IndentWidth: 2, BreakBeforeBraces: Allman, AllowShortIfStatementsOnASingleLine: false, IndentCaseLabels: false, ColumnLimit: 0 } -fallback-style=LLVM -sort-includes=0

Instead, -style=file along with the proper -assume-filename=... should be used.

[sean-mcmanus]

Yeah, it's a bug on Linux -- it isn't detecting the .clang-format file. It doesn't repro on Windows. We should have a fix in a future release. We haven't implemented -assume-filename support yet -- if you want that you could add a separate feature request. We support .clang-format style files (and _clang-format files will be supported in a future release).

[sean-mcmanus]

The fix should be in the upcoming 0.9.1 release (only supports ".clang-format" though). The release after that should support "_clang-format".

[sean-mcmanus]

Should be fixed in 0.9.2.

FYI, it's still not working for me in 0.9.2

VS Code: 1.5.3, C/C++ Extension: 0.9.2, Ubuntu 15.10, 4.2.0-42-generic

[sean-mcmanus]

On Ubuntu 14 I'm not reproing the bug. Do you have another formatter extension installed? If you change the fallback-style does it change?

Extensions:

$ code --list-extensions
donjayamanne.python
lukehoban.Go
ms-vscode.cpptools

On further testing, I think you are correct it is working but how it works can be confusing. Let me explain:

When I set "C_Cpp.clang_format_fallbackStyle": "LLVM" without a .clang-format file it worked as expected (2 space indents, etc.)

I reset "C_Cpp.clang_format_fallbackStyle": "Visual Studio". Then I created a .clang-format with the Linux Kernel style (http://clang.llvm.org/docs/ClangFormatStyleOptions.html#examples):

BasedOnStyle: LLVM
IndentWidth: 8
UseTab: Always
BreakBeforeBraces: Linux
AllowShortIfStatementsOnASingleLine: false
IndentCaseLabels: false

Now it did not work as expected. Indentation was displaying 4 spaces indents like Visual Studio style. (Hence why I originally believed it to not be working.)

In a Terminal I then ran

$ cat example.c

And noticed the indentation was correct. (8 space indents)

So, the problem appears to be with VS Code ("editor.detectIndentation": true) not detecting a file full of hard tab indents and respecting the Unix de facto standard that hard tabs are always 8 characters. This means that out of the box, VS Code + ms-vscode.cpptools cannot work with Linux Kernel formatted code. Given the amount of Linux Kernel style formatted code out there, this seems like a a failure of https://en.wikipedia.org/wiki/Principle_of_least_astonishment.

[sean-mcmanus]

Okay, so the C++ extension is not buggy, right? It sounds like you were seeing a 4 space indent due to the VS Code "editor.tabSize": 4 setting. We only control what happens after a format operation and we also get the tabSize/insertSpaces results (e.g. if detectIndentation sets those). The editor.tabSize setting needs to match the .clang-format TabWidth or things will look off. The Visual Studio style will detect the editor's tabSize and insertSpaces and use those for formatting, otherwise it's from the .clang-format and the spacing of tabs is from editor.tabSize still.

Correct, the C/C++ extension works as designed. However, as designed as a system VS Code + C/C++ extension + automatic clang formatting is confusing.

On all platforms, a hard tab is defined to occur every 8 spaces. Linux, BSD and OSX TTY drivers all follow this convention. So does Windows Command Prompt/Console and Windows Powershell. We can wish it was defined to be another size (like 4) but history has spoken and it's 8 in all modern TTY implementations.

Other Linux code editors (e.g. the big two Vim and Emacs) default to assume hard tabs will be 8 spaces. Then they introduce mechanisms to allow indentation size to be changed independent of tab size based on configuration. By doing this by default most C/C++ files (even those with different indent spacing) can be loaded in those editors and look correct.

It would be great if out of the box, VS Code assumed that hard tabs were 8 spaces like Vim and Emacs and set default indentation to be 4 character spaces (as is now.)

"editor.tabSize": 4, // actually indent size... but keep as is for backward compatibility
"editor.hardTabSize": 8, // doesn't exist today
"editor.insertSpaces": true,
"editor.detectIndentation": true,

However this is not possible with VS Code today because it has muddled together the concepts of hard tab width (a text encoding detail) with indent amount (a logical concept). This is a solved problem in Vim and Emacs. Because of this, with VS Code + C/C++ Extension there are coding styles in place on teams that it cannot support (e.g. the one above.)

In addition, I still find it odd that "editor.detectIndentation": true doesn't detect a file that only contains leading tabs to have a tabSize of 8.

As is, I can guarantee you I won't be the last person to get confused when they apply a .clang-format with UseTab in it and then get confused why the result looks fine in Vim and Emacs but not in VS Code.

[sean-mcmanus]

All you have to do to get what you want is set "editor.tabSize": 8. Visual Studio and VS Code chose 4 as the default tabSize (and if you think they should change that you can post an Issue in the vscode forum); however, it looks like VS Code 1.6 enables some ability to set settings so maybe we could change that default to 8 for C/C++, but I'm not sure yet (VS Code has Vim/Emacs extensions so maybe they do that already). Adding a hardTabSize setting is not necessary. It is the same as the tabSize when insertSpaces is false. Mixing hard and soft tabs in the same file is not recommended...I don't understand why you would want a soft tabSize of 4 but a hardTabSize of 8. With insertSpaces true, inserting a hard tab is not possible without bypassing the insertSpaces somehow. Let me know if you know of an open source project that has a coding style we aren't supporting sufficiently.

I don't understand why you would want a soft tabSize of 4 but a hardTabSize of 8.

This is two questions.

Q1. Why do I want hardTabSize of 8?

Because this is the *nix standard and because of this tools like cat, diff, git, vim, emacs, cut and pasting from the Terminal window, etc. all use this standard out of the box so I'd like to set it to 8 and forget about it and have things just work. This way I can open data files, Makefiles (that often contain hard tabs in them), etc. and not have to worry about whether the tab size is set correctly for them to display correctly.

Q2. Why do I also want tabSize of 4?

Because I don't always want 8 character indents of C/C++ code. More specifically because I don't always work on greenfield projects and therefore I encounter existing code that follows various standards of 8, 4 or 2 character indentation and have 8 character tabs in the files either intentionally or not.

Example file:

void foo() {
    while(1) {
        bar();
    }
}

Using clang-format, this style could be expressed as:

BasedOnStyle:  LLVM
IndentWidth:     4
TabWidth:        8
UseTab:          Always

Using Vim it's easy to edit and maintain this style by putting this in my .vimrc file:

set softtabstop=4
set shiftwidth=4

Using Emacs it's easy to edit and maintain this style by putting this in my .emacs file:

(setq c-default-style "linux"
      c-basic-offset 4)

If you just type this file into Vim or Emacs with the above settings or pipe it through clang-indent with the above settings you will get this exact hex dump:

00000000  76 6f 69 64 20 66 6f 6f  28 29 20 7b 0a 20 20 20  |void foo() {.   |
00000010  20 77 68 69 6c 65 28 31  29 20 7b 0a 09 62 61 72  | while(1) {..bar|
00000020  28 29 3b 0a 20 20 20 20  7d 0a 7d 0a 0a           |();.    }.}..|

Notice 09 tab on the bar() line but only spaces used for 4 character indent on other indented lines.

Unlike Vim, Emacs and clang-indent VS Code cannot be practically used to edit and maintain code in a project with this style.

All you have to do to get what you want is set "editor.tabSize": 8

This doesn't work in the above example. This will allow me to view a file using the style above but I cannot easily edit it and maintain the 4 character indentation.

Mixing hard and soft tabs in the same file is not recommended

This might be a good idea for greenfield projects, however both Vim and Emacs take a different stance and embrace encoding 8 character tabs by default. Even when you want to change indent size with each of them, the simple approach will still encode 8 character tabs as I've shown above. Because of this, there is lots of real world code out there with embedded 8 character tabs.

For greenfield projects I'd prefer something like:

BasedOnStyle:  LLVM
IndentWidth:     4
TabWidth:        8
UseTab:          Never

... and something similar in the editor.

This would allow me to create new C/C++ projects with 4 character indent using spaces. However, with TabWidth set to 8 it would still allow me to open legacy C/C++ files, data files, terminal cut and pastes, etc. with embedded 8 character tabs all in the same editor without needing to reconfiguration editor on a file by file basis. However, VS Code cannot do this.

Anyway, I hope this example makes it clear that VS Code needs to support 8 character tabs independently of indent width if it wants to be a C/C++ editor capable of working with any existing C/C++ code.