Clang, the 8192nd

[Rumchiller]

Hi there, for your information:

 

Environment: VisualStudio 2017, VisualGDB 5.4R2, CMake 3.13, Embedded Project with libraries.

Problem: When including headers, e.g. #include “generic.hpp”, clang sometimes can not find that file (Project compiles successfully):

[+0:06:05.534] Active document changed to C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp
[+0:06:05.534] Active source file for header discovery changed to C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp.
[+0:06:05.534] Checking C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp for missing headers…
[+0:06:05.534] Updating CodeJumps labels for 0 objects…
[+0:06:05.534] No CodeJumps labels need updating. Cancelling aggregate search.
[+0:06:05.534] No missing headers for C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp.
[+0:06:05.534] Starting operation: Parse – Check
[+0:06:05.535] Starting operation: Reparsing C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp
[+0:06:05.535] Previously missing generic.hpp is still missing
[+0:06:05.535] Previously missing generic.hpp is still missing
[+0:06:05.535] Saved data for C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp is up to date.
[+0:06:05.535] Checking C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp for missing headers…
[+0:06:05.535] No missing headers for C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp.
[+0:06:05.535] Starting operation: Exporting parse results
[+0:06:05.536] Operation completed: Exporting parse results [1 msec]
[+0:06:05.536] Checked C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp: 2 error records
[+0:06:05.536] Operation completed: Reparsing C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc\asdf.hpp [1 msec]
[+0:06:05.536] Operation completed: Parse – Check [2 msec]
[+0:06:05.594] Starting operation: Parse – HighlightBraces
[+0:06:05.594] Operation completed: Parse – HighlightBraces [0 msec]

It seems this is a bug: In another opened file (same CMake target) clang can find this include. Clean and build doesn’t fix this issue. After restarting VisualStudio clang finds the include.

 

Greetings!

[Rumchiller]

The 8193rd 😉

When opening VisualStudio and loading a project (same env. like in my first post), some files are still opened in the editor. It happens, that some files will not be parsed by clang:

[+0:18:24.560] Starting operation: Parse – HighlightBraces
[+0:18:24.560] Cannot retrieve source backend for C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:18:24.560] Operation completed: Parse – HighlightBraces [0 msec]

After closing the file and reopen it, clang works as expected:

[+0:21:23.378] C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp belongs to a compatible project (C:\EasyMachines\EasyRotorBalancer\firmware\vgdb.vgdbcmake) and will be handled by our engine
[+0:21:23.378] C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp belongs to a compatible project (C:\EasyMachines\EasyRotorBalancer\firmware\vgdb.vgdbcmake) and will be handled by our engine
[+0:21:23.405] Indentation size: 4, will insert tabs
[+0:21:23.409] Starting operation: Determining code formatting settings for C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.409] Operation completed: Determining code formatting settings for C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp [0 msec]
[+0:21:23.427] Active document changed to C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.428] Active source file for header discovery changed to C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp.
[+0:21:23.428] Checking C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp for missing headers…
[+0:21:23.428] Updating CodeJumps labels for 0 objects…
[+0:21:23.428] No CodeJumps labels need updating. Cancelling aggregate search.
[+0:21:23.428] No missing headers for C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp.
[+0:21:23.428] Starting operation: Parse – Check
[+0:21:23.428] Starting operation: Reparsing C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.430] C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp has not changed since last build. Doing a quick recheck…
[+0:21:23.434] Found an outdated PSF 0 due to C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\os\inc\thread.hpp (expected 885/1548354330, got 885/1548354829) during initial check. It will be re-built.
[+0:21:23.435] Rebuilding PSF 0 (normal preamble)…
[+0:21:23.435] Starting fpsBuildingPreamble on C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.757] Completed fpsBuildingPreamble on C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.757] Successfully rebuilt PSF 0 (normal preamble)…
[+0:21:23.757] Saving PSF 0 (normal preamble) to C:\EasyMachines\EasyRotorBalancer\firmware\CodeDB\vgdb.vgdbcmake-Debug\app.npd…
[+0:21:23.757] Starting fpsSavingPSF on C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.759] Completed fpsSavingPSF on C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.759] Successfully saved PSF 0 (normal preamble)…
[+0:21:23.759] Starting fpsParsingFileBody on C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.817] Starting fpsAnalyzingReferencesLightweight on C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.824] Completed fpsAnalyzingReferencesLightweight on C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.827] Completed fpsParsingFileBody on C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp
[+0:21:23.827] Checking C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp for missing headers…
[+0:21:23.827] No missing headers for C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp.
[+0:21:23.830] Starting operation: Exporting parse results
[+0:21:23.831] Operation completed: Exporting parse results [0 msec]
[+0:21:23.831] Checked C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp: 0 error records
[+0:21:23.831] Operation completed: Reparsing C:\EasyMachines\EasyRotorBalancer\firmware\src\app\app.cpp [403 msec]
[+0:21:23.831] Operation completed: Parse – Check [403 msec]
[+0:21:23.891] Starting operation: Parse – HighlightBraces
[+0:21:23.891] Operation completed: Parse – HighlightBraces [0 msec]

 

Greetings!

[Rumchiller]

Regarding the first problem, I forgot to mention, that generic.hpp belongs to a interface library.

[support]

Hi,

No problem, we can help you. The second problem turned out to be our bug introduced by a recent refactoring. It was on our radar, but we were not aware it affects regular (non-ESP32) CMake projects as well. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2765.msi

The first problem might be caused by the CMake (not reporting the correct include directory for the specific file), or by VisualGDB (e.g. mapping the path incorrectly). In order to narrow it down, please follow the steps below:

• Identify the exact location of the missing header.
• Open Clang IntelliSense Diagnostics Console and switch it to the Project view. Locate the source file that triggers the problem and check its CFLAGS. If the CFLAGS are empty, check the project’s CFLAGS. Do the CFLAGS reference the correct directory? If not, do they mention a similar directory (that would result from invalid path mapping)?
• If the directory is not correct, or is missing, please check the CodeModel.json file in the VisualGDBCache directory. This is the code model reported by CMake. Does it report the correct include directory for the correct source file? If you are not sure, please attach the code model file and let us know the path of the source file triggering the problem and and the header file that is missing.

[Rumchiller]

Hi,

the second problem gone with the new build 2765, thanks for that.

 

Regarding the first problem:

1. I create a new file inside one of my library targets and include that header file in my target_sources (not necessary but my I prefer this way because of my CMake script)
2. The include path was already set and working
3. I rebuild the project
4. I open the new header file (test.hpp), an already existing header file (drivers.hpp) and getting the beheavior like in the attached image.

Then I followed your guide:

1. I located the header (test.hpp) inside the Clang Intellisense Diagnostics Console. It has a red cross and no CFLAGS. The header drivers.hpp also has a red cross. There are a many files with a red cross. It seems that all header files have a red cross. Maybe this is related to the fact, that I include the header files in target_sources?
2. The projects CFLAGS shows the correct include directory “C:\EasyMachines\EasyRotorBalancer\firmware\src\modules\system\inc”.
3. I have no CodeModel.json file inside my project. The only existant json-Files are “VSWorkspaceState.json” and “ProjectSettings.json” inside the .vs-directory.

 

Thanks in advance!

Attachments:

You must be logged in to view attached files.

[Rumchiller]

So now the problem is getting bigger. In some file clang cannot find the headers. It’s undefined behavior, because when I restart VS the headers in one file are found, in another not. Another problem is, that VGDB shows some header files twice in project explorer.

Please see the attached image and clang log dump.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The red cross in front of the header file means that it does not participate in build. This is expected for header files – they are never compiled directly and are always analyzed in the context of a source file (.cpp) including it. Please try reproducing the original problem with the missing headers when including them from a source file, not another header file. If it can only be reproduced when including files from headers, please ensure that the header file triggering the problem is actually included from one of the sources (otherwise VisualGDB will try to guess the compiler flags for it based on the most commonly used flags and it may not be accurate for multi-target CMake projects).

The CodeModel.json file should be located in the following path:

<Directory of the main CMakeLists.txt file>\<Binary Directory from VisualGDB Project Properties>

If your project was imported from a different directory, please search the subdirectories of that directory for the CodeModel.json file instead of the directory of the VisualGDB project itself.

The double header problem could be caused by enabling the automatic header location inside the target directories. Please double-check the “VisualGDB Project Properties -> CMake Project Setings -> Automatically find header files” setting. It needs to be set to “Disabled” if your headers are explicitly specified via CMakeLists.txt files.

[Rumchiller]

Please try reproducing the original problem with the missing headers when including them from a source file, not another header file.

Ok, this is the behaviour:

1. My “generic-lib” contains one dummy.cpp file and apart from that is a header only library. All properties of this CMake target (sources, include-dirs) have public scope.
2. All my other libraries have mixed private and public scope properties.
3. I created two files, “file1.cpp” (private scope) und “file2.cpp”(public scope) and added them as sources to my library “lib”.
4. Now <generic.hpp> can be only found in “file1.cpp”, but not in “file2.cpp” (???).
5. Now just setting “file2.cpp” to private scope: et voila, <generic.hpp> can be found.
6. Now setting both files to public scope, that clang shouldn’t find the headers anymore: That’s right, clang can not find them. BUT:
7. After project clean and rebuild, <generic.hpp> is always found in both source files, whether they have public or private scope. This behaviour is ok for me.

There was no include of <generic.hpp> inside any of my source files. I included it in two source files in each library (one in a public scoped source, one in a private scoped source). First there was no effect. After a rebuild no effect to. Buf after a VS-restart a few clang errors regarding the missing header file were gone.

When there is a file, that I leave opened in the editor and the header cannot be found in it, I restart VS and now it can be found. It’s a very strange behaviour.

My project has an out of source build, but looks as follows:

– project

• build
  • …
• CodeDB
• src
  • …
• VisualGDBCache
• CMakeLists.txt (main cmake-file)
• Other VGDB-Files like .mak, .sln, .xml, .vgdbcmake

In the whole project there is no such file.

Another thing: Is it possible to deactivate the jumps inside the project explorer when changing the active file inside the editor? It’s clear, that the engine can not know at which library I am working at, so it jumps to the first one in the list. This makes the navigation really, really bad on big projects, due to the fact, that all folders become elapsed after the jump.

• This reply was modified 5 years, 10 months ago by support. Reason: formatting
• This reply was modified 5 years, 10 months ago by support. Reason: formatting

[Rumchiller]

I am very sorry for the bad formatted post. But this post editor is very very ….. bad 😉

[support]

Thanks for the update. Not sure what you meant about private and public-scope source files. CMake libraries typically have private and public header search paths and properties, but there should be just one list of source files. If you believe this is caused by some specific layout of your libraries, could you try reproducing it on a clean CMake project and send it to us? If we could reproduce the problem on our side, we should be able to fix it (or suggest a workaround).

If not, please use this build. It will show the path to the CodeModel.json file in View->Output->Advanced VisualGDB Projects Output (search the window contents for CodeModel.json).

The jumps inside Solution Explorer are handled by the VS itself. Visual Studio 2017 does not switch the active file automatically and provides a button for doing that instead. If this doesn’t work, please attach a screenshot of the entire VS window showing the problem (please don’t attach cropped screenshots – they hide the state of many common controls, project load status, etc. and generally make it nearly impossible to understand what is going on).

No worries about the editor. We have edited your post fixing the formatting.

[Rumchiller]

Hello!

Sorry for the long absence.

Seems that I have the same problem like described in this post: https://sysprogs.com/w/forums/topic/intellisense-bug-vs-2017/ . I will also try the new build.

[support]

No problem. The new should should indeed make diagnosing of header-related issues much easier.

[b.timofte]

is this fixed in any version i can use ?

[support]

You could try using our latest daily build [VisualGDB-5.4.103.2978.msi]

If it doesn’t help, please refer to the previous thread you created regarding IntelliSense issues: https://sysprogs.com/w/forums/topic/dear-developers-please-add-this-major-functionality/

[Author]

Posts