Recursive parsing does not seem to propagate compilation unit settings #1489
Comments
|
Hi @apriori, thank you for the ticket. Indeed, it looks like the preprocessor applies the include paths only to the first-level includes. I will double-check it. Does this issues affects you in any other way, other then the console warnings? If you have a squid-rule @guwirth the maintenance of existing preprocessor code contradicts to #1484. Please comment, which strategy should we follow. Regards |
|
Hi @ivangalkin, I also realized that there are problems with the preprocessor. There is also #1225 to fix. For me it's not interesting because we use anyway external tools for issue validation.
Think the discussion how to proceed in general with the parser will take longer. My proposal is to fix #1489 and #1225. Regards, |
|
Hi @apriori, I tried to reproduce your issue and didn't succeed (I used different include nestings, the quote includes, angle-bracket includes etc). The preprocessor code looks correct to me, too. Is it possible, that your compilation database is not consistent? E.g. the following lines indicate, that some include paths do not exist or were not expanded properly: Could you please check your JSON file and/or provide an example, which could help us to reproduce the issue? Thank you! |
|
@ivangalkin I just manually replaced parts of the as with "$root" to denote, that this is the project root part, so the content should not be considered literally. I'll try to come up with an example. And yes, it makes the analysis virtually useless, because classes of depending headers are not parsed and then considered parser errors in the .cpp lacking its definitions. I'll recheck the compilation database. It would not surprise me that there is something "odd" with it, because frankly, this whole procedure with the database is a mere hack. |
- support Microsoft Quoted form search (close SonarOpenCommunity#1225): 1) In the same directory as the file that contains the #include statement. 2) In the directories of the currently opened include files, in the reverse order in which they were opened. The search begins in the directory of the parent include file and continues upward through the directories of any grandparent include files. 3) fallback to use include paths instead of local folder (same as Angle-bracket form) - add #include unit tests - test for compilation database settings propagation (close SonarOpenCommunity#1489) - refactoring
- support Microsoft Quoted form search (close SonarOpenCommunity#1225): 1) In the same directory as the file that contains the #include statement. 2) In the directories of the currently opened include files, in the reverse order in which they were opened. The search begins in the directory of the parent include file and continues upward through the directories of any grandparent include files. 3) fallback to use include paths instead of local folder (same as Angle-bracket form) - add #include unit tests - test for compilation database settings propagation (close SonarOpenCommunity#1489) - refactoring
Description
When parsing a .cpp file that includes another in bracket form, the parser fails to locate headers included
in the second file, because the include path information provided by the compilation unit of the root file are not recursively propagated.
Steps to reproduce the problem
Have a .cpp file like this:
(CLI.cpp)
(ApplicationController.h)
(compile_commands.json)
[ { "directory": "/root", "command": "/usr/bin/clang++-6.0 -DQT_NO_DEBUG -I/opt/Qt/5.10.0/gcc_64/include -I. -I/opt/Qt/5.10.0/gcc_64/include/QtCore -I/opt/Qt/5.10.0/gcc_64/mkspecs/linux-g++ -O3 -DNDEBUG -Wall -Wextra -Wpedantic -Werror -fPIC -std=gnu++1z -o CLI.cpp.o -c CLI.cpp -I/usr/include/c++/7 -I/usr/include/x86_64-linux-gnu/c++/7 -I/usr/include/c++/7/backward -I/usr/lib/gcc/x86_64-linux-gnu/7/include -I/usr/local/include -I/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed -I/usr/include/x86_64-linux-gnu -I/usr/include", "file": "CLI.cpp" } ]Expected behavior
Upon analysis of CLI.cpp, Squid should parse the file, hit the include line, and then recursively continue, always propagating root include path configuration.
Actual behavior
As indicated in the logs, instead, when the "ApplicationController.h" is parsed, Squid falls back to only use the global settings. Which is clearly wrong.
LOG file
Related information
The text was updated successfully, but these errors were encountered: