Community
Participate
Working Groups
I am working with a C project that uses Eclipse generated makefiles. Those same build settings set the compiler to use C99 (or specifically GNU99) and provide several defines like _GNU_SOURCE. However the indexer, and as a consequence the content assistant and semantic validation checks don't function properly. The validation checks don't recognize the bool primitive type so they report it missing.
Created attachment 196119 [details] Screenshot showing GNU99 enabled...
Created attachment 196121 [details] Screenshot showing defined symbols that be enabling glibc functions.
I misspoke above; the content assistant is still showing the alternate function name. But when the syntax highlighter does't show references as external SDK calls.
It is unclear to me what kind of problem you are observing. It'd be best to provide steps to reproduce what you are seing and describe what you would expect instead. In C99 'bool' is not a primitive type. You can either use '_Bool', or you need to include 'stdbool.h' which defines the macro '#define bool _Bool'. So the observation, that 'bool' is not recognized is an indication that either your code is wrong, or the include search path for the parser is not setup correctly. Please provide a code snippet + a parser log (context menu of file in project explorer - index - create parser log) and a description what you would expect to behave differently.
I've managed to reproduce the issue with the general release version of Indigo. Although the issue seems to only surface intermittently and according to my casual observations after working for an extended period of time. In the parser log I saw: Macro definitions (from files actually parsed): Unresolved includes (from headers in index): file:/usr/lib/gcc/x86_64-redhat-linux/4.4.5/include/stdbool.h is not indexed Unresolved inclusion: freetype/config/ftheader.h in file file:/usr/include/ft2build.h It could be that the problem is because 4.4.5 is a link back to 4.4.4 on RHEL 6: [ladar@magma /]$ ls -l /usr/lib/gcc/x86_64-redhat-linux total 8 drwxr-xr-x. 4 root root 4096 Nov 23 2010 3.4.6 drwxr-xr-x. 7 root root 4096 Feb 14 17:16 4.4.4 lrwxrwxrwx 1 root root 5 May 19 15:11 4.4.5 -> 4.4.4 Attached are screenshots showing the problem inside the IDE, a screenshot of the folder mentioned, and a parser log.
Created attachment 198700 [details] Screenshot showing my_bool as an unresolved symbol.
Created attachment 198701 [details] Screenshot showing gcc linkage on RHEL 6.
Created attachment 198702 [details] Parser log.
Please check whether stmts.c is actually indexed. For that, try to open it in the Include Browser, for that use 'Show In - Include Browser'.
(In reply to comment #9) > Please check whether stmts.c is actually indexed. For that, try to open it in > the Include Browser, for that use 'Show In - Include Browser'. It opens in the include browser and seems to be finding all of the other symbols used in that particular file without issue. Rebuilding the index and restarting Eclipse didn't seem to help.
Created attachment 199514 [details] Screenshot showing include browser.
Created attachment 199535 [details] Screenshot with possible clue. This may indicate the issue. From this screenshot you can see the my_bool type is defined in two places. In looking at the headers, you can see that preprocessor logic is used to ensure the type is only defined once. But for some reason the indexer seems to pick up the deceleration twice.
Created attachment 199536 [details] Indexer settings. My indexer settings. I've asked it to parse unused files so that even symbols/headers I'm not currently using will be available via the content assistant.I presumed that only the symbols actually available at compile time would be used/available. That doesn't appear to be the case here.
(In reply to comment #13) > Created attachment 199536 [details] > Indexer settings. > My indexer settings. I've asked it to parse unused files so that even > symbols/headers I'm not currently using will be available via the content > assistant.I presumed that only the symbols actually available at compile time > would be used/available. That doesn't appear to be the case here. While the preprocessor can make sure that only one version of my_bool is used per translation-unit, the two versions can still be used by different translation units. In any way, how do the two declarations look like. Can you use them to create a small example that shows the same issue?
Created attachment 199560 [details] c source file I haven't been able to narrow down the problem; so creating a test case project will take some hunting and pecking. I did notice the MySQL viosocket.c file declares functions with a my_bool return type and the return type is followed immediately by a line break and then the function name. The unusual formatting might explain the viosocket.c references in attachment 199535 [details].
Created attachment 199561 [details] Screenshot showing the abnormal formatting.
Created attachment 199584 [details] Test case. The attached workspace will demonstrate the bug. But the bug is fickle about switching on and off.
I was in a rush this morning and couldn't fully write out what I found. If I exclude the viosocket.c file from the project's build configuration, the indexer seems to properly handle the my_bool typedef and the waterboard test project passes all of the semantic validation checks. Since I'm building MySQL from the command line and only want the files in my workspace for reference, excluding the file was simpler than reformatting it. I should note that I still can't seem to switch the issue on/off reliably since rebuilding the indexes doesn't seem to take into account the changes I make to the MySQL project's configuration. Any pointers? You might also want to test the indexer against the ClamAV 0.97.1 source code. The parser seems to run into problems with the libclamav/c++/llvm/ sub-directory. I don't know if its the same issue, or something unrelated.
Looks like the problem is about parsing viosocket.c. The file + a parser log may reveal why this is the case.
Created attachment 200576 [details] Parser log. Attaching a parser log for viosocket.c. The viosocket.c file is from the MySQL 5.1.57 tarball. Any plans to fix this for SR1 release?
(In reply to comment #20) > Created attachment 200576 [details] > Parser log. > Attaching a parser log for viosocket.c. The viosocket.c file is from the MySQL > 5.1.57 tarball. > Any plans to fix this for SR1 release? This looks like a setup issue, the file 'viosocket.c' is parsed without the include search path and the macro definitions that are built into the compiler.
Its been awhile since I looked into this, but as I recall one of the problems is the indexer won't properly pickup the my_bool typedef. That particular typedef is defined in two header files. I traced the include files loaded via the mysql.h file and that chain does include both headers. You'll see that the second my_bool typedef should be skipped via preprocessor conditionals but isn't. And based on my limited testing, this symptom would disappear once the viosocket.c file has been excluded from the build configuration. I couldn't figure out what the relationship is between the index parsing error and the header files. If you look at the test project, and locate where I declare a my_bool variable you'll see that the code analysis thinks the type is unresolved. And if you try to open the my_bool declaration you'll be asked whether to visit the mysql.h or my_global.h headers. Like I said above, the my_global.h typedef should be skipped once the mysql.h file is processed.
Created attachment 202647 [details] Video showing bug reproduction steps. I may have found the culprit. When I add the MySQL project as a referenced project to torture, and then rebuild the index, the parser fails me. If I remove the project reference and rebuild the index it works again. I created a short video to demonstrate the bug in action. The capture omitted video frames where nothing occurred so you may want to slow the playback for easier viewing.
(In reply to comment #23) This indicates that viosocket.c is parsed incorrectly within the project MySQL. When adding the project reference the wrong declarations from this project cause the problem. --> You need to fix the setup of project MySQL.
How is the configuration wrong? The MySQL project builds just fine. Do I need to add specific include files and export them for it to work?
(In reply to comment #25) > How is the configuration wrong? The MySQL project builds just fine. Do I need > to add specific include files and export them for it to work? The parser log of viosocket.c indicates that you don't have the include search path pointing to the compiler builtin directories. You can try to go to the scanner discovery property page, check the settings, clear the discovered entries and start a build on the project to trigger the discovery. This may generate the correct include paths for the project.
Created attachment 203557 [details] Torture includes... The torture project has the correct includes, even which is why it compiles, and the mysql project seems to be configuring itself using autotools. I also tried setting up the mysql project to 'export' the mysql/include path but that didn't seem to help.
Created attachment 203558 [details] MySQL includes. As you can see the default include paths seem to be auto-discovered...
Created attachment 203559 [details] Test projects as gzipped tarball. Projects exported to gzipped tarball so others can try... and if the bug attachment fails, try: http://www.filedropper.com/torturetar_1
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
