Closed tristanlabelle closed 1 month ago
I'd be happy to submit a PR but I can't find how the string is referenced: https://github.com/microsoft/vscode-cpptools/blob/fc5a084781aab590d0220f2ac4ff3c3e3cfcaec8/Extension/src/nativeStrings.json#L241
I don't think you need a PR, can you just set the C_Cpp.configurationWarnings
setting to "disabled"
? Maybe that's a bigger hammer than you want, but as long as CMake reports your compiler this way, we'll try to use it. I don't recall off hand whether we have a way to override the configuration provider's compiler. Perhaps @Colengms or @sean-mcmanus knows.
As far as I know there's no way to override configuration provider's compiler path.
Why is our extension being run on Swift files? We don't currently support Swift. Can the files.associations be changed such that our extension doesn't process the files?
There are C files in the workspace, so we get activated and will try to get the system includes before we index it.
@bobbrow You mean .c files that are actually Swift files? That should be fixed by setting files.associations appropriately, such as
"files.associations": {
"**/DotNetMetadataCInterop/*.c": "swift"
}
Or CMake Tools or some Swift extension or us could maybe do that automatically?
I don't think it matters if we're activated if the file is not associated with C/C++ then we won't process it, although maybe setting the files.association might also fix the activation.
I've boiled it down to a more minimal repro where nothing should cause the C/C++ extension to be involved
CMakeLists.txt
:
cmake_minimum_required(VERSION 3.21.0)
project(Repro LANGUAGES Swift)
CMakePresets.json
:
{
"version": 3,
"configurePresets": [
{
"name": "default",
"generator": "Ninja",
"binaryDir": "${sourceDir}/build"
}
],
"buildPresets": [
{
"name": "default",
"configurePreset": "default"
}
]
}
.vscode/settings.json
:
{
"C_Cpp.configurationWarnings": "disabled"
}
CMake: Configure
commandA few seconds after CMake configure completes, the focus switches to the C/C++ Configuration Warnings
pane, which shows:
[9/14/2024, 6:43:07 AM] Unable to resolve configuration with compilerPath "c:/users/tristan/appdata/local/programs/swift/toolchains/0.0.0+asserts/usr/bin/swiftc.exe". Using "cl.exe" instead.
(note that the C_Cpp.configurationWarnings
config did not prevent this)
CMake should be able to report a per-language compiler path so it seems like a bug that the C/C++ Extension ends up with the swiftc.exe
path at all when it should only query the compiler for C and for C++ languages.
Thanks for the update @tristanlabelle,
I'm sorry, I gave you wrong information about that setting. It does not actually control this scenario.
I don't currently see any way to disable that behavior besides disabling the C++ extension for that workspace. CMake Tools activates the C++ extension automatically because it calls our API. It's possible that CMake Tools could be improved to not call our API and activate our extension if it detects that there is no C or C++ code that needs configurations, but in the meantime, if you don't need C++ support active, there should be no harm in disabling the extension for that workspace.
To do this, go to the Extensions tab and click the gear for the extension (lower right corner): Then choose "Disable (Workspace)"
Thanks as well for the follow-up. Unfortunately, this solution would regress our developer experience. While I am able to reproduce the issue with a minimal Swift-only project, all of the real-world projects in which we encounter this bug (including The Browser Company's main codebase) have a mix of Swift and C/C++ files. This interoperability is also a selling point of Swift, so it's a common scenario.
There's a few ways this could be solved (best to worse):
swiftc
It seems likely that the issue is in this integration: https://github.com/microsoft/vscode-cmake-tools/blob/d860f0859de84de5babc043f5896d1f6a3033be0/src/cpptools.ts#L508 .
@gcampbell-msft Should this be moved to the vscode-cmake-tools repo?
@tristanlabelle @gcampbell-msft, my guess is that CMake Tools should skip the SWIFT compiler kind of like what we did for RC a long time ago. I think the fix would go here: https://github.com/microsoft/vscode-cmake-tools/blob/d860f0859de84de5babc043f5896d1f6a3033be0/src/cpptools.ts#L434
Ping @gcampbell-msft !
@tristanlabelle When we use the reproduction steps you provided to reproduce the issue, we get this error, can you give some advice?
@v-frankwang , it looks like you don't have Swift installed as in my repro steps. where.exe swiftc.exe
in the terminal should print the path to the swiftc compiler
@tristanlabelle I still get the error after installing the Swift compiler. Error message.txt
@v-frankwang please make sure to open VS Code from a VS Developer Command prompt which reports x64 for both host and target:
C:\Code>set VSCMD_ARG
VSCMD_ARG_HOST_ARCH=x64
VSCMD_ARG_TGT_ARCH=x64
You might want to use the explicit x64 Native Tools Command Prompt for VS 2022
shortcut in the start menu.
@tristanlabelle For the fix that @bobbrow pointed out, is the filegroup language for swift simply "swift"?
@gcampbell-msft , I don't know what that filegroup
concept is. It doesn't seem to come from CMake, from a code search, so I assume it comes from the CMake Tools extension?
@tristanlabelle I'll investigate, thanks.
@tristanlabelle Could you test out the fix in this vsix?
You'll have to change the file extension from .zip to .vsix after downloading.
@gcampbell-msft Sorry for the wait. Yup! That fixed it with my repro. Mind @'ing me in the PR?
Environment
Bug Summary and Steps to Reproduce
Bug Summary: While working on a CMake Swift project, the C++ extension will regularly print the message below to the
C/C++ Configuration Warnings
output window righ after a build, which is annoying because:CMake/Build
output pane, hiding the output of the buildswiftc.exe
compilerSteps to reproduce:
Generator
subfolder in VS Code from a VS dev cmdcmake --preset debug
andcmake --build --preset debug
(the bug is not specific to this repo, I see it regularly when working in Swift)Expected behavior: The C/C++ extension should not produce this warning. Probably it should ignore anything to do with the Swift compiler.
Configuration and Logs