Update 1.19.4 breaks wildcard operator '*' in tasks.json code will not compile about vscode-cpptools HOT 13 CLOSED

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.

from vscode-cpptools.

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?

from vscode-cpptools.

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.

from vscode-cpptools.

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.

from vscode-cpptools.

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.

from vscode-cpptools.

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.

from vscode-cpptools.

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).

from vscode-cpptools.

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?

from vscode-cpptools.

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.

from vscode-cpptools.

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

from vscode-cpptools.

@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

from vscode-cpptools.

@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!

from vscode-cpptools.

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

from vscode-cpptools.