Support compiler querying (fo scripts) that depend on a particular current working directory

[tcm0116]

Environment

• OS and Version: Ubuntu 18.04
• VS Code Version: 1.77.3
• C/C++ Extension Version: v1.14.5
• If using SSH remote, specify OS of remote machine: N/A

Bug Summary and Steps to Reproduce

Bug Summary:

Our project utilizes Bazel and uses a tool to generate a compile_commands.json file that is intended to be used by the C/C++ IntelliSense engine. In our case, the compiler provided in the compile_commands.json is actually a script that sets some environment variables and eventually executes the actual compiler. However, we're running into an issue when IntelliSense is generating the database where the following error is generated:

Querying compiler for default C++ language standard using command line: /home/thomas/workspace/external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/wrappers/x86_64-linux-gnu-gcc-9 -x c++ -E -dM /dev/null
Querying compiler for default C++ language standard using command line: /home/thomas/workspace/external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/wrappers/x86_64-linux-gnu-gcc-9 -x c++ -E -dM /dev/null
Detected language standard version: c++98
Querying compiler's default target using command line: "/home/thomas/workspace/external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/wrappers/x86_64-linux-gnu-gcc-9" -dumpmachine
Failed to query compiler. Falling back to 32-bit intelliSenseMode.
Failed to query compiler. Falling back to no bitness.
/home/thomas/workspace/external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/wrappers/x86_64-linux-gnu-gcc-9: line 9: /home/thomas/.cache/bazel/_bazel_thomas/6492692a2eb6be5f61b303fedafae60b/external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/wrappers/external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/toolchain/usr/bin/x86_64-linux-gnu-gcc-9: No such file or directory

As stated above, the /home/thomas/workspace/external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/wrappers/x86_64-linux-gnu-gcc-9 file is actually a script which contains the following line to execute the physical compiler:

exec "external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/toolchain/usr/bin/${NAME}" "$@"

As this is used in a Bazel workspace, an assumption has been made that this script will always be run from the root of the workspace, which is true for typical building activities. However, as can be seen by the path provided for the No such file or directory error, it appears that the C/C++ extension is attempting to query the compiler while the pwd is set to the folder containing the compiler, resulting in the script attempting to execute the compiler at a path relative to its location rather than relative to the root of the workspace.

A simplified version of the compile_commands.json file being used show below and it can be seen that the directory field for each entry is set at the root of the workspace. As such a possible solution for this issue would be to ensure that the pwd is set to the directory when querying the compiler.

[
  {
    "file": "<path_to_cpp_file>",
    "arguments": [
      "external/cc_toolchain_linux-linux-gcc9-x86_64-linux_ubuntu_focal-x86_64/wrappers/x86_64-linux-gnu-gcc-9",
      <additional_compiler_arguments>
    ],
    "directory": "/home/thomas/workspace"
  }
}

Configuration and Logs

A c_cpp_properties.json file is not used, but the following setting is used in the workspace's settings.json to specify the location of the compile_commands.json. No other settings are configured for the C/C++ extension.

"C_Cpp.default.compileCommands": "${workspaceFolder}/compile_commands.json",

[Colengms]

Hi @tcm0116 .

it appears that the C/C++ extension is attempting to query the compiler while the pwd is set to the folder containing the compiler

That's correct. For some compilers that are not in the PATH, and several Windows compilers that are normally hosted in (MSYS or Cygwin) environments, setting the pwd is required to properly locate headers and their own shared libraries in order to execute without failure.

There are a few possible ways we could address this, and conditionally set the pwd. We can use this issue to track investigating those.

[tcm0116]

@Colengms - thanks for the response! We're working with our toolchain vendor to see about updating the script to be insensitive to the pwd, so it's good to have confirmation of our understanding of how the C/C++ Tools extension functions.

While troubleshooting this issue, I've been experimenting with various settings in an attempt to devise a workaround. In the process, I've discovered that setting the path to the actual compiler binary in c_cpp_settings.json via the compilerPath setting does successfully override the compiler specified in the compile_commands.json. However, if the c_cpp_settings.json is omitted and the C_Cpp.default.compilerPath setting in settings.json is set to the compiler binary, it does not successfully override the compiler specified in the compiler_commands.json. Based this, it appears that the evaluation chain for the compiler is:

c_cpp_properties.json/compilerPath -> compile_commands.json -> settings.json/C_Cpp.default.compilerPath

Is this the expected order of evaluation? I would assume that C_Cpp.default.compilerPath should take prescedence over the compile_commands.json, but it would be great if this could be confirmed.

[sean-mcmanus]

Yes, that is the expected order of evaluation (compile_commands.json takes precedence over C_Cpp.default.compilerPath) -- in general, the "default" settings have a lower precedence since they are defaults if nothing else with a higher precedence is set.

[tcm0116]

@sean-mcmanus - thanks for the clarification! However, the Customizing default settings article doesn't seem to indicate this order of evaluation.

In the Updated c_cpp_properties.json syntax section, it states the following:

If a property is missing from c_cpp_properties.json, the extension will use the value in the VS Code setting.

And then in the System include path/defines resolution strategies section for when the open file is found in the compileCommands database, the following order of operations is listed:

1. If systemIncludePath has a value, use it (continue to the next step to search for system defines).
2. If compilerPath is valid, query it.
3. Interpret the first argument in the command as the compiler and attempt to query it.
4. If compilerPath is "", use an empty array for system include path and defines.
5. If compilerPath is undefined, look for a compiler on the system and query it.

Based on these details, it's not clear from the documentation that the VS Code setting is evaluated differently from the value provided in the c_cpp_properties.json file. If the compilerPath from the VS Code setting does have lower presence than the command from the compile commands database, then it would be helpful if the System include path/defines resolution strategies section could be updated to reflect this.