I am trying the application “KDevelop 5.1.0-26.1” out. I have noticed in a project for Linux source files that problems in semantic analysis can be indicated for some identifiers there. If I inspect include statements at the top of such a source file, they look fine in the way so that I would expect that the needed information can be retrieved from the referenced header files according to the provided project settings for the desired programming language support.
This text is nicely worded but manages to omit all relevant information *grin* Which project do you open? What kind of errors do you see? Do you have a screenshot?
Created attachment 105024 [details] Demonstration for a questionable source code analysis result in the file “pinctrl-imx.c” (In reply to Sven Brauch from comment #1) > Which project do you open? next-patched.kdev4: [Project] Manager=KDevCustomMakeManager Name=next-patched > What kind of errors do you see? Examples: * Implicit declaration of function 'pinctrl_generic_get_group' is invalid in C99 [-Wimplicit-function-declaration] * Incompatible integer to pointer conversion assigning to 'const struct group_desc *' from 'int' [-Wint-conversion] * Forward declaration of 'struct group_desc' Would you like to look at further software development challenges around a source file like “https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/pinctrl/freescale/pinctrl-imx.c?h=v4.10”? > Do you have a screenshot? Do you get further ideas from such a picture?
I would appreciate another comment for my attachment 105024 [details].
It considers that struct a forward declaration, which causes the warning. Something's missing, either an include path, or some define ... can you look if any includes are missing in the path to the source file which defines this struct?
(In reply to Sven Brauch from comment #4) I can imagine that my project settings for KDevelop could be still incomplete. * The interpretation of a pointer specification as a forward declaration can be occasionally appropriate. An other source code analysis display seems to indicate that an identifier could just not be resolved so far. * The include statements should be complete in the mentioned source file example. * Are there any other constraints to consider for the affected development environment?
Maybe some header included by a file included by this one is not found? You should be able to get to the definition of this struct just by Ctrl+Click-ing on the #include directives ... Or is the struct maybe in some #ifdef?
(In reply to Sven Brauch from comment #6) > Maybe some header included by a file included by this one is not found? I can follow that related difficulties can occasionally occur because of recursive file inclusion. But this is not the case here because a relevant header file is directly referenced at the top of the affected source file. > You should be able to get to the definition of this struct The information for a data structure like “group_desc” is not provided by the analysis popup window so far. > just by Ctrl+Click-ing on the #include directives ... The corresponding header files are shown as expected after clicking on a quotation character besides the specified path. > Or is the struct maybe in some #ifdef? Yes. - See also the corresponding change “pinctrl: stricten up generic group code” from 2016-12-30 for example. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/pinctrl/core.h?id=c033a718f615b6b3ddc83ce3e0a217c30bd09cb5 Do I stumble just on the situation that the source code analysis configuration is different from the final build environment at the moment?
Yes, it apparently has some #defines which KDevelop doesn't know of. Add them in your project configuration (right-click project, open configuration) under "Includes/Defines", then it should work.
(In reply to Sven Brauch from comment #8) Would it make sense to clarify similar extensions for the source code analysis configuration around the mentioned symptoms a bit more? Are there interesting further software development opportunities?
You mean, show a hint that a define is missing in order to have that struct defined? That would certainly be useful, but I'm not sure how difficult it is to do. Is your problem solved?
(In reply to Sven Brauch from comment #10) > You mean, show a hint that a define is missing in order to have that struct defined? Yes. - I am thinking also about possibilities in such a direction. Could such functionality help in the better understanding of the involved dependencies? > Is your problem solved? The answer depends on your views around the responsibilities for an advanced software development environment like KDevelop. 1. It seems that I needed a refresh for the current version of this evolving tool. I got information about further system configuration possibilities. 2. I imagine that the mentioned source code analysis display can still be improved. I assume that the discussion for my clarification requests could be continued with the evolution of the provided add-ons/plug-ins. The presented information can be correct for my selection of an analysis environment. But they could also be interpreted in another way besides a misconfiguration, couldn't they? 3. I dared to look at an intermediate development status of some source files for a known software where my own knowledge is still incomplete. Now I wonder about the situation if a preprocessor symbol like “CONFIG_GENERIC_PINCTRL_GROUPS” (from the header file “drivers/pinctrl/core.h”) should also appear in the source file “drivers/pinctrl/freescale/pinctrl-imx.c”. Do specifications need to be extended for conditional compilation there?
Well, my primary concern is whether our software does the right thing given that you configured it correctly -- i.e. told it about the defines in your compiler. Since that seems to be the case I'll close this. In general, deducing compiler settings automatically works very good for high-level build systems such as cmake or qmake; you wouldn't have that problem there. With make, it's always hard to figure out, but if you have an idea how to improve it, patches welcome ;)
(In reply to Sven Brauch from comment #12) > Well, my primary concern is whether our software does the right thing given > that you configured it correctly How do you think about to reconsider any related software infrastructure? Will any further tweaks become relevant for source code inspection there?
(In reply to Markus Elfring from comment #13) > How do you think about to reconsider any related software infrastructure? > Will any further tweaks become relevant for source code inspection there? Sorry, I find it hard to understand what you mean -- what "related software infrastructure"?
(In reply to Sven Brauch from comment #14) How many software components are involved in the display of source code analysis results?
So by "related software infrastructure" you mean "KDevelop"? That's not super intuitive wording. Even with that, I don't know what you mean; the issue is that we need to know the compiler defines, and those are not so easy to figure out from Makefile projects. As said, suggestions and patches welcome.
(In reply to Sven Brauch from comment #16) I assume that KDevelop is also a platform (or host) for some plug-ins, isn't it? Which software is responsible for presenting information around a source code identifier in a popup window?
That code is in KDevelop itself, in the NavigationWidget class. The issue is not there though.
(In reply to Sven Brauch from comment #18) > That code is in KDevelop itself, in the NavigationWidget class. It seems that the background parser can need a remarkable time frame for data processing of corresponding information from a big code base like Linux. * In which source files are related widgets implemented? * Do they cooperate with any document classes? > The issue is not there though. Which details should be found at other places? How are the chances to increase the awareness for further solutions from software development challenges around preprocessor symbols?
(In reply to Markus Elfring from comment #19) > (In reply to Sven Brauch from comment #18) > > That code is in KDevelop itself, in the NavigationWidget class. > > It seems that the background parser can need a remarkable time frame for > data processing of corresponding information from a big code base like Linux. Yes, because there is a remakrable amount of information to be retrieved and stored. > * In which source files are related widgets implemented? kdevplatform:language/duchain/navigation/abstractnavigationwidget.cpp > * Do they cooperate with any document classes? Yes. > How are the chances to increase the awareness for further solutions from > software development challenges around preprocessor symbols? Sorry, not intending to be rude, but can you try to use a bit less words and say a bit more with them? I struggle to understand the phrase "increase the awareness for further solutions from software development challenges around preprocessor symbols". Do suggest to add a `add preprocessor define` button to the problem navigation widget?
(In reply to Sven Brauch from comment #20) > kdevplatform:language/duchain/navigation/abstractnavigationwidget.cpp Can such source files also be viewed by a web interface for a content management system? > I struggle to understand the phrase … I get inspiration for related improvement possibilities the more I am increasing my software development activities with KDevelop again. * There is a general issue around source code refactoring, isn't it? The addition of a preprocessor symbol by a button or menu entry would be a nice option in the discussed graphical user interface. Will a corresponding refactoring browser become available? I imagine that additional perspectives can also help. * A tool was developed for Linux to check for build configuration errors. How much can it matter also for other source files?
(In reply to Sven Brauch from comment #20) > I struggle to understand the phrase "increase the awareness for further solutions …". Do you find any information from a report like “Three talks on kernel development tools” for the 2014 Linux Plumbers Conference relevant for this issue? https://lwn.net/Articles/617383/
Sorry, I don't see what this leads to in context of this bug report :/ If you have a concrete suggestion on what to improve and how, please submit a patch to phabricator.kde.org or start a thread on the development mailing list.