specific files.exclude pattern not working: path[^\\/]*

[bwsnico]

Environment

• OS and Version: Windows 11
• VS Code Version: 1.78.2
• C/C++ Extension Version: v1.16.3

Bug Summary and Steps to Reproduce

Bug Summary:
Since the update to v1.16.* a special files.exclude-pattern doesn't work anymore. There has been a fix to #8960 and that seems to break the following exclude glob:

"Source[^M\\/]*": true,

It should exclude everything but the folder/files containing Source/ and SourceM. It works well for search and Files-Explorer, but IntelliSense is not able to find any files inside the Source/ path.

Testet with these pattern, too. Also not working:

"Source[^M/]*": true,
"Source[^M\\]*": true,
"Source[^/]*": true,
"Source[^\\]*": true,

"Source/[^*]": true, is working, but then I see no chance to "allow" SourceM4 as well.

Configuration and Logs

No response

Other Extensions

No response

Additional context

No response

[jacksonc-xlnx]

I have also observed this. The following doesn't seem to prevent the parser from iterating through all of these directories since v1.16.*:

"C_Cpp.files.exclude": {
        "**/external": true,
}

It will still go through the entirety of this directory.

[Colengms]

Hi @jacksonc-xlnx . We recently addressed a number of issues with (and perf of) exclusion support by moving to essentially the same algorithm used by VS Code to interpret and process them.

In the simple example, ("**/external"), I'm not able to repro an issue with 1.16.3. Using the following:

    "C_Cpp.files.exclude": {
        "**/external": true
    },

And issuing Reset IntelliSense Database, I see that the contents of folders with that name are not scanned. Then, upon removing the setting, I see they are scanned as expected:

  tag parsing file: Z:\repos\test2\external\external_test.h
  tag parsing file: Z:\repos\test2\src\external\external_test2.h
  tag parsing file: Z:\repos\test2\src\external\nested\nested_test.h

If you're seeing something different, could you provide a stand-alone example, such as in the form of a zip file or a GitHub repo, that we might investigate further?

Also, I don't believe the following are valid for VS Code exclusions (at least on Windows?). When I try to use these, files are not excluded within the explorer view:

    "files.exclude": {
        "Source[^M\\/]*": true,
        "Source[^M\\]*": true,
        "Source[^\\]*": true
    }

Although the remaining two appear to work as expected in the explorer view:

        "Source[^M/]*": true,
        "Source[^/]*": true,

If you reload the window to cause search exclusion to be applied (which seems to require a reload for some reason), you'll see that the same logic is being applied to search includes as is being applied by the C/C++ Extension.

It's by design that we should now match the behavior of VS Code's exclusions (with a slight caveat that we also support full path exclusions, such as for system includes, where VS Code always refers to files and folders under the workspace folder). As such, I'd like to consider this external, and suggest opening a bug against VS Code on the (inconsistent) behavior evident with these patterns in their explorer view and in search. If VS Code were to support these patterns as you expect, the C/C++ Extension should (be fixable to) support them as well. Or, if they are able to provide you an alternative set of patterns that work in VS Code itself, the C/C++ Extension should support them also.

[bwsnico]

Also, I don't believe the following are valid for VS Code exclusions (at least on Windows?). When I try to use these, files are not excluded within the explorer view:

    "files.exclude": {
        "Source[^M\\/]*": true,
        "Source[^M\\]*": true,
        "Source[^\\]*": true
    }

I don't use them all together, it was meant to be used one by one with a reload one each try...
Under Windows it is important to use the backslash, otherwise the Source folder it not visible in the Files view.

To give a clearer view of what I'm trying to describe, I've created a little test environment. Also available under github:
https://github.com/bwsnico/issue11132

Workspace-file (SourceWorkspace.code-workspace):

{
	"folders": [
		{
			"path": ".",
		},
	],
	"settings": {
		"C_Cpp.default.compilerPath": "D:/XMaster5-Buildtools/msys/2.0/mingw32/bin/clang.exe",
		"C_Cpp.default.intelliSenseMode": "windows-clang-x86",
		"C_Cpp.default.includePath": [
			"${workspaceFolder}/Source/**",
			"${workspaceFolder}/SourceM4/inc/**"
		],
		"C_Cpp.loggingLevel": "Information",
		"files.exclude": {
			"Source[^M\\/]*": true
		}
	}
}

File structure:

.
|   README.md
|   SourceWorkspace.code-workspace
|
+---Source
|   |   main.cpp
|   |
|   \---inc
|           Test.h
|
+---SourceKernelModule
|       .gitkeep
|
+---SourceM4
|   \---inc
|           Shared.h
|
\---Source_Test
        .gitkeep

main.cpp

#include "Test.h"
#include "Shared.h"


int main(int argc, char** argv)
{
  return 0;
}

Expectation / Problem

The only visible folders in the Files view are Source and SourceM4. That's correct so far. See also the screenshot below.
If I open the main.cpp file, there are include errors for both Test.h and Shared.h.

So why is VSCode itself able to find the files and the extension or IntelliSense is not?

Additional info: It is not a include-path problem, it is working well if I switch to v1.15.4

[Colengms]

Hi @bwsnico . Thank you for the repro. I did find a bug with handling of path delimiters. I'm working on a fix, and it should be in the next release.

[michelleangela]

Fix available in pre-release https://github.com/microsoft/vscode-cpptools/releases/tag/v1.17.0.

[Colengms]

Hi @bwsnico . Could you confirm whether the fix in 1.17.0 fully addresses your scenario?