Vscode-cpptools: Unable to set non-recursive includePath in workspace root

[mill1000]

Type: LanguageService

Describe the bug

• OS and Version: Windows 10 (Windows_NT x64 10.0.17134)
• VS Code Version: 1.30.2
• C/C++ Extension Version: 0.21.0
• Other extensions you installed (and if the issue persists after disabling them): None

I am unable to set a non-recursive includePath to the workspace root. I wish to add specific folders to the includePath, and exclude others. However since they are all subfolders of the workspace root, they are automatically included. It appears the extension always adds the workspace root as a recursive includePath.

Example c_cpp_properties.json

{
  "configurations": [
      {   
          "name": "MinGW",
          "intelliSenseMode": "gcc-x64",
          "compilerPath": "C:/msys32/opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe",
          "includePath": [
              "${workspaceFolder}/Sub/Include/**",
              "${workspaceFolder}/Main/**",
              "${workspaceFolder}/*"
          ],
          "defines": [
            "__GNUC__=5"
          ],
          "cStandard": "c11",
          "cppStandard": "c++14"
      }
  ],
  "version": 4
}

The C/C++ log shows the root folder is included recursively.

Code browsing service initialized
Populate include completion cache.
Discovering files...
  Processing folder (recursive): C:/MSYS32/OPT/XTENSA-ESP32-ELF/LIB/GCC/XTENSA-ESP32-ELF/5.2.0/INCLUDE/
  Processing folder (recursive): C:/MSYS32/OPT/XTENSA-ESP32-ELF/LIB/GCC/XTENSA-ESP32-ELF/5.2.0/INCLUDE-FIXED/
  Processing folder (recursive): C:/MSYS32/OPT/XTENSA-ESP32-ELF/XTENSA-ESP32-ELF/INCLUDE/
  Processing folder (recursive): C:/MSYS32/OPT/XTENSA-ESP32-ELF/XTENSA-ESP32-ELF/SYSROOT/USR/INCLUDE/
  Processing folder (recursive): C:/PATH/TO/ROOT/
  Discovering files: 1060 file(s) processed
  0 file(s) removed from database
Done discovering files.
Parsing remaining files...
  Parsing: 3 files(s) processed
Done parsing remaining files.

Expected behavior
I should be able to control the inclusion of the workspace root in the includePath. i.e. Set to non-recursive or exclude entirely.

[sean-mcmanus]

The "Processing (recursive)" is controlled by the "browse.path" setting and not the "includePath" setting, i.e. use

            "browse": {
                "path": [
                    "${workspaceFolder}/*"
                ]
            }

That setting is for global symbol parsing (although if it's missing we attempt to populate it from the includePath). Since the includePath doesn't support "*", it looks like we don't transfer the "*" over to the browse.path automatically, i.e. we can probably fix that so it's less confusing.

The includePath is non-recursive by default (without any *).

[sean-mcmanus]

Ah, it looks like your pull request transfers over the "*" -- that seems good to me.

UPDATE: Your fix shipped with 0.22.0-insiders.

[mill1000]

Ah well, the whole browse.path vs includePath can be quite confusing. Haven't quite wrapped my head around it.

Yes copying over the non-recursive "*" got the behavior I was looking for. Quick fix.

[KaeLL]

Ah well, the whole browse.path vs includePath can be quite confusing.

True that. Seems like unnecessary redundancy. What's the difference between them, and does it justify having both? I mean, it's almost unquestionably easier to control recursion using the asterisk rather than 2 separate elements in the json file that do the same thing.

A little less important, but just as interesting: why 2 asterisks to signal recursion? It's essentially like forcing to or to not put a slash at the end of a path ( /home vs /home/ ). I mean, it's obviously implicit that mentioned folders should be added regardless of ending forward slashes or asterisks. What's not implicit is the recursion. It should be something like this
Non-recursive version:
/home or /home/
Recursive version:
/home/*
This is exactly how Unix's ls works. Simple, clear, and familiar.

/home/** is just unnecessarily... fancy.

[sean-mcmanus]

@KaeLL Originally, we just had the browse.path, which was automatically recursive and "*" was used to make it non-recursive, which is what @mill1000 wanted to set. Later we added includePath but it was non-recursive by default (* didn't do anything). Then we added recursive includes, but since browse.path already used "*" to mean non-recursive, we used "**" to mean recursive for the includePath setting.

[KaeLL]

So... shall I open an new issue requesting the said change?
To clear the confusion before it gets worse and harder to fix

[sean-mcmanus]

Sure, you can open an issue, but I don't think we would fix it. The current behavior with "*" and "**" isn't really broken. "*" always means non-recursive and "**" always means recursive. Changing it to the opposite would confuse our existing users and we'd have to update everyone's settings. I seem to recall there was some other tool that used "*" to mean non-recursive.

[KaeLL]

It's more about the redundancy and convolution of browse.path, includePath, *, **. It's ugly and dumb.
Anyway, I won't bother making a case for it, I'm just telling what it is. Thanks anyway.