March 20, 2019 at 13:41 #24375
since the last VisualGDB update to 5.4R3 a yellow bar with a button labeled “Refresh” beneath the navigation bar shows up on every file in all projects. It says “The current file is not built by any known projects or included by any known sources. IntelliSense will be less accurate this is resolved” on source files and “The current header file is not included by any knows sources. IntelliSense will be less accurate until the file is included from a C/C++ source.” on header files. See screenshots. It doesn’t make any sense to me, since all headers are included somewhere, all source files are used in the build and the projects compile successfully without errors. Clicking the refresh button changes nothing. In some files IntelliSense does not recognize standard library headers such as memory or vector or the google test header. This never showed up before the update. I don’t know how to get rid of it.
What could be the cause for this? What information do you need to reproduce it?
VisualGDB Custom Edition version 5.4R3 build 3013
Visual Studio Community 2017 version 15.9.9
Attachments:You must be logged in to view attached files.March 20, 2019 at 17:35 #24385
The previous versions of VisualGDB would still try to guess the IntelliSense parameters for the files that are not directly compiled, but would indeed not show the warning.
Either way, we can help you pinpoint this. Please identify a specific source file that triggers the problem and take a note of its full path (right-click on the document tab header and select “copy full path”). Then open View->Clang IntelliSense Diagnostics Console, switch it to the Project Structure view and check if the file is listed there with the exactly the same path. If it is not and you are not sure why, please share more details about your project (project type, what files from the project are listed, what are not, etc.).
Please also try reducing the solution to just 1 project (ensure you reload it afterwards) – it should make diagnostics easier.
If the problem only happens for header files, please let us know and we will share updated instructions.March 21, 2019 at 09:13 #24389
The solution consists of five projects (boot strapper, boot loader, two main applications and a test suite). There are shared files that are included by only some of the projects. In the Clang IntelliSense diagnostics console only a single project is listed under the project structure view. This is the first project that was created when the solution was created. The files that show the warning are not included or built by this particular project and are therefore not listed in the Clang console. The projects contain a lot of files so I didn’t check every single file. But it looks like all the files used by the project listed in the Clang console show no warning. All other files used exclusively by one of the other four projects show the warning. Both header and source files are affected.
As you suggested I unloaded all projects except for one. I chose a project that was not listed in the Clang console before. The Clang diagnostics console contained no entries after that and IntelliSense painted everything red. After restarting Visual Studio the project popped up in the clang diagnostics console and IntelliSense worked fine. No warnings in any of the files of the project. Reloading other projects after that adds them to the Clang console with their respective files. Except for the test suite which shows up as ‘???’ with no files listed. Maybe that’s because it is a Win32 project instead of a VisualGDB project? I haven’t encountered any warnings since, so unloading and reloading all projects in a multi-project solution seems to fix the issue temporarily.
However, once I restart Visual Studio with all projects loaded, again only a single project shows up in the Clang IntelliSense diagnostics console (the project that was listed there initially). The problems with IntelliSense not working in files of other projects and warnings showing up appear again.
How can I have all projects of the solution permanently taken into account by Clang IntelliSense? Unloading and reloading every single project on every start up of Visual Studio is no viable option.March 21, 2019 at 21:46 #24407
No worries, we understand that reloading the projects manually each time is very inconvenient. We only suggested doing this to narrow down the problem to a specific project/setting.
The “???” display for non-VisualGDB projects is also by design.
Please try opening View->Clang IntelliSense Diagnostics Console->Log when the solution is not open, clearing it and loading the solution. Then check the log for red error lines. If attaching to one of the projects triggers an unexpected exception, this might prevent VisualGDB from attaching to further projects during the same operation. We should be able to fix this once we know more details.
If this doesn’t help, please try creating a copy of the .sln file, then remove half of the projects from it and load the new solution (ensure you delete the .vs folder to clear out any caches). Then repeat it until you find a minimal combination of projects that does not load properly when opening the solution and check if there is anything different about the project triggering the problem.March 22, 2019 at 09:02 #24414
Thank you for the support so far.
While following your instructions to diagnose the problem I found out that the issue only occurs when I have Visual Studio set to load the last loaded solution on startup or when I open the solution by double-clicking the .sln file. So if I close Visual Studio and open it again, it loads the solution automatically. In this case however, only one of the five projects in the solution is attached in the Clang IntelliSense diagnostics console. Same if I open the solution by double-clicking the .sln file. If I manually close the solution and then open it manually from within Visual Studio, or if I set Visual Studio to not load a solution on start up and manually open it from the recent projects and solutions list, all five projects of the solution are recognized by Clang IntelliSense and everything works fine.
There are no error lines in the Clang diagnostics log when loading the solution either way. If the solution is opened automatically by Visual Studio on start up, the log contains only operations for one project. When I manually open the solution from within VS these log entries appear for each project in the solution. For instance:C++12345[+0:00:00.000] Starting operation: Wrapping [path]\[projectname].vcxproj[+0:00:00.121] [path]\[projectname].vcxproj: found xsource files[+0:00:03.669] Starting operation: Reporting x+ 0 extra sources to Clang engine...[+0:00:03.676] Operation completed: Reporting x+ 0 extra sources to Clang engine... [6 msec][+0:00:03.684] Operation completed: Wrapping [path]\[projectname].vcxproj [3681 msec]
Additionally lines like the following show up. These do not appear when manually opening the solution from within VS.C++1[+0:00:03.706] [path]\[filname].cpp will be handled by Clang IntelliSense because all open projects have it enabled
I also tried modifying the .sln file as you suggested. I found out that when loading the solution automatically on start up, or opening it via the explorer only the first project listed inside the .sln file is attached to Clang. If I change the order of projects in the .sln file, always only the first project in the list is recognized by Clang. The number of projects in the .sln file does not seem to matter. I removed all but two projects. Still, only the project listed first in the .sln file appears in the Clang diagnostics console.
This issue is probably related to Visual Studio and not VisualGDB. I will take to opening solutions from within Visual Studio. That resolves the issue for me.March 22, 2019 at 19:14 #24444
Thanks for pointing this out. It turned out to be our bug – in the recent V5.4R3 update we optimized the initialization logic of VisualGDB: instead of loading during Visual Studio startup, it would only get initialized once a VisualGDB-based project is loaded, or any of the VisualGDB-related commands is used. It turns out, when loading the multi-project solutions via command line, Visual Studio sent some of the project load events in a slightly different order, that caused VisualGDB to miss some of them.
We have fully fixed the issue in the following build: VisualGDB-18.104.22.16822.msi
Sorry for the inconvenience and thanks for providing sufficient details for us to reproduce the issue.
You must be logged in to reply to this topic.