Update 1.19.4 breaks wildcard operator '*' in tasks.json code will not compile

[venkat-ranganathan]

Environment

• OS and Version: macOS Sonoma 14.3.1 (23D60)
• VS Code Version: Version: 1.86.2
  Commit: microsoft/vscode@903b1e9
  Date: 2024-02-13T19:42:12.210Z
  Electron: 27.2.3
  ElectronBuildId: 26908389
  Chromium: 118.0.5993.159
  Node.js: 18.17.1
  V8: 11.8.172.18-electron.0
  OS: Darwin arm64 23.3.0
• C/C++ Extension Version: 1.19.4 (1.18.5 works as expected)
• If using SSH remote, specify OS of remote machine:

Bug Summary and Steps to Reproduce

Since this morning I can no longer use the wild card operator to compile multiple files with the same extension, this was previously working as expected since I configured it a year ago.

The same command works if I type it in the terminal manually, i.e. "clang -g *.c"

This problem is compiler agnostic, the same error shows up if I try to use gcc instead of clang

Steps to Reproduce:

configure tasks.json to launch all files with the same extension using *.c, for example:

"type": "cppbuild",
"label": "C/C++: clang build multiple files",
"command": "/usr/bin/clang",
"args": [
"-fcolor-diagnostics",
"-fansi-escape-codes",
"-g",
"*.c",
],
"options": {
"cwd": "${fileDirname}"
},
"problemMatcher": [
"$gcc"
],
"group": "build",
"detail": "Task generated by Debugger."

Error

attempt to compile code using task
receive the following error:

Starting build...
/usr/bin/clang -fcolor-diagnostics -fansi-escape-codes -g '*.c'
clang: error: no such file or directory: '*.c'
clang: error: no input files

Expected behavior:

should compile the same as when user enters the same command in terminal manually

Configuration and Logs

c_cpp_properties.json never changed

Other Extensions

remote SSH
remote SSH editing
remote explorer
material icon theme
monokai vibrant theme
monokai night theme
python
pylance
python debugger
vscode pdf

Additional context

No response

[Colengms]

Hi @venkat-ranganathan . I believe what you're seeing is actually 'by design'. When represented as an array, we do not expect arguments to contain shell escaping or other special shell characters. When present, they are now properly escaped. This recently changed, to address users' issues with args that refer to paths (containing special characters) that not being properly escaped, resulting in failing commands.

I believe the proper solution here would be either for us to add an addition field for a command line fragment (allowing a partial command line, where shell escaping would be expected/supported), or allow arguments to also be included in the "command" field (which seems appropriately named to do so). I think the later may be more straight-forward. (The compilerPath field in c_cpp_properties.json works this way.) I'd like to use this issue to track adding that.

[ecurtz]

Quoted from The Linux Getting Started Docs
Modifying tasks.json
You can modify your tasks.json to build multiple C++ files by using an argument like "${workspaceFolder}/*.cpp" instead of "${file}".This will build all .cpp files in your current folder.

So either the design has changed or this new behavior isn't actually correct.

[Colengms]

Hi @ecurtz . Thanks for bringing that documentation issue to our attention.

In the past, as we've addressed issues from users who have effectively expected arguments to support or not support shell escaping (these expectations are mutually exclusive), we've inadvertently ping-ponged the behavior back and forth. To resolve the confusion and ambiguity, we've adopted a consistent design pattern throughout the C/C++ extension:

• Any time you are working with an array of arguments, those arguments are expected not to have shell escaping present and will not receive shell processing.
• Only a command line or a command line fragment (which may contain multiple arguments), is expected to have shell escaping potentially present.

This parallels similar expectations of the command and arguments field in a compile_commands.json file.

This is also consistent with VS Code's default task provider, which does not expect shell escaping within an args array: https://code.visualstudio.com/docs/editor/tasks

A command line is a shell concept, and an array of arguments (i.e. argv in main()) are not implicitly shell concepts. (Shell escaping would presumably have already occurred when converting a command line into an array of arguments, as shell escaping is involved in disambiguating how arguments are delimited).

Currently, in a compilerArgs field of c_cpp_properties.json, since it is an array of args, we do not expect shell escaping to be present. If shell escaping is needed there, a command line can be provided in the compilerPath field and those arguments will receive (limited) shell processing.

Similarly, our custom configuration provider API accepts these separately in compilerArgs and compilerFragments fields.

[starball5]

Related on Stack Overflow:

• (canonical) VS Code C/C++ cppbuild task doesn't support globbing when args is an array. Why?
• (duplicate) cant find *.cpp

[wbkboyer]

This is the cpp tools extension, but this new behaviour breaks C/C++ compiling on Windows with MinGW gcc, gcc on MacOS, and clang on MacOS. The behaviour of quoting the args is not present on v1.18.5 and breaks for v1.19.4:

Starting build...
C:\MinGW\bin\gcc.exe -fdiagnostics-color=always -g C:\Users\wbkbo\git\edge-addition-planarity-suite-fork\c\**.c -o C:\Users\wbkbo\git\edge-addition-planarity-suite-fork\c\planarity.exe

compiles with v1.18.5 on Windows with MinGW gcc, vs. the build command

Starting build...
"C:\MinGW\bin\gcc.exe" -fdiagnostics-color=always -g "C:\Users\wbkbo\git\edge-addition-planarity-suite-fork\c\**.c" -o "C:\Users\wbkbo\git\edge-addition-planarity-suite-fork\c\planarity.exe"
gcc.exe: error: C:\Users\wbkbo\git\edge-addition-planarity-suite-fork\c\**.c: Invalid argument
gcc.exe: fatal error: no input files
compilation terminated.

Build finished with error(s).

This is based on the following args in tasks.json for MinGW gcc

 "args": [
                "-fdiagnostics-color=always",
                "-g",
                "${workspaceFolder}\\c\\**.c",
                "-o",
                "${workspaceFolder}\\c\\planarity.exe"
            ],

And for clang:

"args": [
                "-fcolor-diagnostics",
                "-fansi-escape-codes",
                "-g",
                "${workspaceFolder}/c/**.c",
                "-o",
                "${workspaceFolder}/c/planarity"
            ],

Is there any feasible alternative to using ** expansion for when we wish to include multiple .c files in the build command?

[john-boyer-phd]

Original response: > Hi @venkat-ranganathan . I believe what you're seeing is actually 'by design'.

Hi @Colengms, It doesn't seem that this can be by design when the cppTools are now broken on C/C++ compiling of larger-than-hello-world projects for multiple compilers on multiple platforms. It would be helpful to roll back the fix then develop a different fix for the original problem that was being solved so that the different fix solves the problem without also breaking most compile jobs.

[starball5]

When I try using a string instead of an array for args, I get this hover tooltip:

Incorrect type. Expected "array".
Additional arguments to pass to the compiler or compilation script.

This is my build task:

{
   "type": "cppbuild",
   "label": "multiple cpp files",
   "command": "/usr/bin/g++",
   "args": "-Wall -Wextra -g -fdiagnostics-color=always ${workspaceFolder}/**/*.cpp -o ${workspaceFolder}/build/multiple-cpp-files",
   "problemMatcher": ["$gcc"],
},

And trying to run the build task anyway gives me the message

There is no task provider registered for tasks of type "cppbuild".

I'm on v1.19.4 of this extension. What's going on?

[starball5]

@john-boyer-phd my advice: do yourself a favour and build your larger-than-hello-world project with a buildsystem. Read bottom paragraph of https://stackoverflow.com/a/78058239/11107541

[john-boyer-phd]

starball5 > @john-boyer-phd my advice: do yourself a favour and build your larger-than-hello-world project with a buildsystem. Read bottom paragraph of https://stackoverflow.com/a/78058239/11107541

I think you wouldn't be pleased to go to the doctor, say "doctor, it hurts when I do this," and then have the doctor say "well then don't do that."

Same idea, i.e., thanks for your advice, but I'd like to use the built-in build system that worked until it got broken. When the built-in build system works, it's easy to use the dev environment to set up and debug a straightforward multifile project (a hello world program only has one file, and the quote marks don't seem to get added when there's only one file).

[bobbrow]

We have been discussing this issue as a team and will be reverting the behavior to re-align with how VS Code's tasks work. This will be fixed in 1.19.5 which should be released this week.

[john-boyer-phd]

We have been discussing this issue as a team and will be reverting the behavior to re-align with how VS Code's tasks work. This will be fixed in 1.19.5 which should be released this week.

Thank you Bob, we really appreciate your expedient decision and action on this issue.

[spotter1006]

@bobbrow, thanks for finding the two related issues (spaces and asterisks). Many of us have been spinning our wheels with workarounds. I am glad you guys are on top of this!

[sean-mcmanus]

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.19.5