GNOME Bugzilla – Bug 623633
Include pre-compiled database for standard C and C++ libraries
Last modified: 2020-11-06 20:21:58 UTC
Currently, we don't autocomplete the C standard library and the C++ STL at all because they are obviously not using pkg-config and thus, we don't find them. For C, the problem is that we really don't want to use every single file in /usr/include but only those which are part of the standard. For C++, we should better use a simple version of the STL without macro stuff like http://www.vim.org/scripts/script.php?script_id=2358 The C stuff actually doesn't really change at all and for C++ it also takes ages until there is really a new version of the library with API changes so this should be rather save.
*** Bug 566979 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > > For C++, we should better use a simple version of the STL without macro stuff > like http://www.vim.org/scripts/script.php?script_id=2358 > I guess line numbers will not correspond correctly to user's installation. Our symbol-db allows navigating to header files, so in such cases we would need to prevent navigation.
> I guess line numbers will not correspond correctly to user's installation. Our > symbol-db allows navigating to header files, so in such cases we would need to > prevent navigation. Agreed, but I think that's a minor issues compared to not having completion at all. And believe me, the C or C++ standard headers aren't that interesting to look at ;)
we can ship a .db together with the anjuta distribution. At symbol-db global db load, we check if the c-stl and c++-stl exists. If not we would attach those external databases. Would it be an acceptable solution?
(In reply to comment #4) > we can ship a .db together with the anjuta distribution. > At symbol-db global db load, we check if the c-stl and c++-stl exists. If not > we would attach those external databases. > > Would it be an acceptable solution? I think for C we can easily parse the system headers (I will implement this with the move to language-support-cpp-java. I think I would rather call that package glibc though. For C++, the proposed solution is good.
So, C headers are scanned now in symbol-db-refactor branch. Some methods are defined as macros there though and aren't shown completely and some are built-in (strcmp, strlen, etc.).
I see that working, that's a good add on ;) I'm changing a little bit the signals handling on symbol-db core to: 1. make easier to scan more system packages (internally speaking). 2. code cleaning in scanning process. 3. improve life-cycle of scan process.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/anjuta/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.