Tagged: clang static-analysis
January 11, 2018 at 09:43 #13397
In the VGDB settings, there is an option to enable Clang Static Analysis. I’ve enabled it, but it doesn’t seem to do anything. I couldn’t find any documentation about this in the manual and forum, so I hope someone can give me a primer on how it actually works.
Let me give you my setup, in case you can stop what is wrong:
- IDE: VS2017
- VGDB 5.3 Preview 8
- C++ project uses cmake/ninja.
How I created my project:
- New Linux project
- Import a CMAKE project (“Advanced” option unchecked)
- Source code is located in Windows, and copied over to Linux VM for compilation
- gcc toolchain is used in the VM.
- IntelliSense Settings = “Use default per-user setting (Clang-based)”
- Code Analyzers = “Enable static code analysis”.
As an example, I have
core.unitialized.Assignedchecked. Then, I wrote this code:C++12int x;x |= 1;
The compilation passed, and I was able to deploy to my ARM target. I was expecting a warning, or at least a squiggly line.
Is there an explicit command to perform the analysis? Or is it doing nothing because my toolchain is gcc?January 11, 2018 at 20:39 #13400
The code analysis results are normally shown in the regular Errors pane (and are also highlighted in the code). They don’t interfere with the build and can be distinguished by the “[Clang IntelliSense]” prefix:
If they don’t appear for your project, please try creating a new project from scratch and see if this works. If yes, please try comparing project properties between the 2 projects.
Attachments:You must be logged in to view attached files.January 12, 2018 at 13:14 #13404
Thanks for the screenshot and letting me know it’s automated behavior. It is working now.
While a bit off topic, I still have issues setting up Clang IntelliSense:
(1) From the posts in the forum, I understood that we have to put in the correct flags (-D<xxx>) for the parsing to work. I might have to read up on Clang since I am using GCC… it’s a vague question, but any examples or tutorials for non-Clang users to reap the benefits for Clang IntelliSense will be appreciated.
(2) I am getting simple IntelliSense errors like “vector is not part of the std namespace”. Ok, I understand that the library files are in the VM and not in Visual Studio/PC, so I need to let VisualGDB know about the paths. So, under the “IntelliSense Directories” tab in the Settings, I clicked “Add Remote” and added all the paths in the remote VM, which includes my project’s source headers, the compiler headers (/usr/include/, /usr/lib/gcc), and the paths to my ARM toolchain. I can see that IntelliSense errors related to missing functions from my project is now resolved, but I still face issues with the standard libraries (such as the vector example) and things like “unable to find size_t”. What else do I need to do?January 12, 2018 at 15:56 #13405
Ah, I’ve learned something new.
(1) In the “IntelliSense Directories” tab, I cannot just add a top-level directory and expect the system to traverse recursively … I will need to add each folder explicitly. For
By manually adding these folders one-by-one, I am able to make the system find things like size_t, time_t, etc.
(2) The order in which I place these folders do matter. For example, toolchain folders should be on top, while project folders should be below.
Question: Is there an easier way where I can just put define <toolchain_root_folder> and let change search recursively?January 12, 2018 at 16:42 #13406
<span style=”text-decoration: underline;”>Problem with remote caching:</span> My toolchain folder paths are long. VGDB’s default RemoteSourceCache path is long too given it’s stored in AppData. Some of the files couldn’t be copied, so that explains why Clang couldn’t find certain symbols.
Cannot create C:\Users\kurt\AppData\Local\VisualGDB\RemoteSourceCache\192.168.1.82\0000\usr\src\debug\gcc-runtime\6.3.0-r0\gcc-6.3.0\build.arm-company-linux-gnueabi.arm-company-linux-gnueabi\arm-company-linux-gnueabi\libstdc++-v3\include\bits\stl_iterator_base_types.h: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Q: Is there a way to define where the remote cache is located?
I’m gonna try an alternative of copying the entire toolchain folder to Windows in a shorted path, and see if Clang can find it.January 13, 2018 at 05:43 #13417
Sorry, the remote source cache location is fixed and cannot be changed.
One quick workaround would be to try using the Advanced CMake Subsystem with the direct SSH file access. It will perfectly support long paths, duplicate case-sensitive names and other scenarios that don’t work on Windows.
Another option would be to indeed copy the toolchain directory somewhere locally and then use the header discovery mechanism to quickly locate the missing headers.
You must be logged in to reply to this topic.