Error message in Multi-root project using compile_commands.json does not have enough information #5160
Comments
|
This is referring to the configuration for one of the folders. cpptools should update the message to indicate which folder the configuration belongs to. |
|
What is meant by "configuration". The warning message doesn't mention "configuration". Is this a multi-root only issue? Should the ${workspaceFolder} be replaced by the workspace's name? |
|
By "configuration", I am referring to the c/cpp extension configuration. In the screen shot, the configuration is set to "CMake-Tools" (instead of "Mac"). My c_cpp_properties.json file has the following "configurations": I am using a multi-root workspace and CMake-Tools is set as the configurationProvider. The following is the contents of my .code-workspace file: Resolving the location of a header file can result in multiple paths when using a configurationProvider for a multi root workspace. I have noticed this happens when there is a header that does not have a corresponding ".c" target in compile_commands.json. For instance, my main.c located in the "app" root folder, has the following include: When I right click and select "Go to Definition", I get a window showing multiple paths. <kernel.h> is not located in the app folder, rather it is located in the "zephyr" root folder. I think perhaps the c/cpp extension appears to be attempting to find a "kernel.c" target. Since "kernel.c" is not a target in compile_commands.json, the c/cpp extension defaults to another search process (default include paths) and comes up with multiple paths. It seems that c/cpp should have used the "main.c" target in compile_commands.json? |
|
|
|
I removed the defaults from the .code-workspace file and have only one default setting: c_cpp_properties: I restarted VSCode. Now, all the red squiggles are gone and the log diagnostics shows the correct include paths: The linting appears to be ok but I cannot "Go to Definition" for any include file now. I do not even see a popup with a list of definitions anymore. I see a message "no definition found for ". If I select a function or type and "Go to Definition", VSCode appears to open the correct file with the definition. This is the cleanest it has ever been for me, which is an improvement. The only remaining issue now is I cannot directly open the include files from #include statements. I have to indirectly open them by finding something that references them and then use "Go to Definition". Or, of course, open the include manually. I read the open issue #2564 describing the problem of using Go to Definition on a #include statement. And idea what the ETA on a fix for this is? |
|
The browse.path isn't set automatically when compileCommands is set. See #1163 . If you're using CMake Tools, it's recommended that you not set compileCommands, because the CMake Tools extension will correctly set the browse.path. Sounds like you hit some issue using CMake Tools. |
|
Unfortunately, CMake Tools does not appear to be providing the configuration so I changed my configuration to use compile_commands.json. |
|
This seems more like an issue with the header to source file mappings. @Colengms I'm not sure if there's anything generic we can do here since this file is likely included by multiple source files and we don't know which one to pick. Are we defaulting to header-only IntelliSense in those cases now? @sslupsky can you share the output of "Log Diagnostics" when just the header file is open so we can see whether it is being mapped to a source file? |
|
Here is Log Diagnostics when I right click "Go To Definition" on "#include <device.h>" in "main.c" and then selected the "correct" item from the list: The "device.h" file appears to be mapped to the configuration used for "main.c". I think that is correct. |
|
Did you have main.c open in the editor before device.h was opened? Here's a test. Close all editor tabs except for device.h and then run the "Reload Window" command. When IntelliSense is ready, run the "Log Diagnostics" command and check the mapping for device.h. |
|
In your earlier comment you said that switching to compile_commands.json fixed your problem, but that shouldn't be the case for header files. compile_commands.json doesn't have entries for header files but the configuration provider would have entries if the header files were listed in the CMakeLists.txt file. I would expect compile_commands.json to work only if the source file (e.g. main.c) is also open in the editor. |
|
Here are a couple snap shots of the log diagnostics. They were generated with all tabs closed except device.h. I also reloaded with window. |
|
I think in this case, the compile_commands.json has an entry for "device.c", so it picked that up for the translation unit mapping. |
|
Here is a copy of the entry in compile_commands.json: |
|
And when you do the same exercise with the Configuration Provider set to CMake Tools, what do you get? |
|
Just a note for @elahehrashedi, the original issue here is about the warning message, but we have been discussing additional issues related to this project which will likely need to be split out into another issue. |
|
When I switched my configuration to use CMake Tools as the configuration provider, I saw this message displayed in the output window: After reloading the window, I did not see this message. So in this instance, it appears to have provided the configuration. It appears to have picked a seemingly random translation unit mapping modem_iface_uart.c. Maybe not so random, I believe that was one of the last files I was working on. I did reload the window and the modem_iface_uart.c tab is not open. |
|
When a header file is included by multiple translation units and none of them are open in the editor, we have to guess one. If you end up opening a source file in the editor (e.g. main.c), we will switch over to using that one. The important question is whether you get correct IntelliSense or not in this case. Do you? The configurations are very similar but not exactly the same. I'm just wondering if there are any issues left to track for your setup besides #2564? |
|
Yes, it appears intellisense was linting the code properly in this instance. I am still uncertain why CMake Tools was not providing a configuration for main.c? I removed the default configuration from .code-workspace and switched the configuration for main.c to use CMake Tools as the configuration provider. I reloaded the window. I waited about 30 seconds, all the includes have squiggles. The only open tab is main.c. Here is the log diagnostics: |
|
I do not even know where it is getting that configuration above. I do not have any defaults in the code-workspace and c-cpp-properties default specifies gcc with no includes or defines. So, this must be some sort of system default provided by CMake Tools? |
|
Yes, CMake Tools will provide system info. You can see it in the logging via setting C_Cpp.loggingLevel to "Debug" and looking for "Custom configurations received:". |
|
The configuration for main.c looks wrong and possibly isn't provided by CMake Tools. Checking the logging as @sean-mcmanus mentions would remove all doubt. If that's the case, then we move the investigation back over to CMake Tools. |
elahehrashedi
added
the
fixed
|
@sslupsky Should be fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/0.28.0-insiders2 . |
|
This issue is fixed in 0.28.0. |
Copying this issue over to cpptools where it would need to be addressed.
Originally posted by @sslupsky in microsoft/vscode-cmake-tools#1120 (comment)
One observation is that the error message that indicates an error with the configuration would benefit with additional information about what exactly it is referring to. Here is a screen shot:
What is not clear is which configuration it is referring to. Does the message refer to the configuration in the .code-workspace file or one of the configurations in the c_cpp_properties.json file?
I copied a project directory and renamed it. I have opened the copy and I get the message in the screen shot above. I'm trying to run down where the problem is and it is not obvious.
The text was updated successfully, but these errors were encountered: