Details
-
Bug
-
Resolution: Invalid
-
Not Evaluated
-
None
-
6.6
-
None
Description
Until now the only example of a not-public, not-private category were the QPA headers, but those have all their docs marked as \internal so the problem never came up in practice. The docs for the QPA classes would be broken in the same way as described below, I suppose, but nobody sees it when it's not generated, and perhaps those headers rely less on inline functions (and so \fn) anyway.
Now in QTBUG-113331 another such API category, the "RHI" headers, are introduced, mirroring pretty much what is done for QPA today, so in syncqt and elsewhere we plan to handle these RHI headers the same way as QPA, but one big difference is that documentation is essential for these APIs.
However, we see that the resulting documentation is heavily crippled. E.g. docs for inline functions are all missing, the \fn stuff in the .cpp are just ignored.
While docs are generated seemingly correctly for the classes and regular functions that are all defined and documented in the .cpp files (so not with \fn or similar), inline functions that have a corresponding \fn in the .cpp are all skipped. Same goes for struct members from the .h documented with \variable in the .cpp, and possibly some other things
With QDOC_DEBUG=1 the logs show that the structs and classes from the .h files are in fact not seen at all when processing the \fns, presumably because these headers and so any classes in them are is not in the precompiled header at all.
It seems it all boils down to this logic here in buildPCH() in qdoc:
https://code.qt.io/cgit/qt/qttools.git/tree/src/qdoc/qdoc/clangcodeparser.cpp#n1412
Meaning that for a Qt module like QtGui it looks for the QtGui module header that includes all the .h files but only the real public ones, excluding any .h from special categories such as QPA (or soon RHI). Not listing these headers in the module include is logical since the module header cannot include headers that are not includable out of the box in a plain application, but for qdoc's purposes this is not sufficient.
If I change that condition to always hit the first branch (i.e. pretend that header.isEmpty() is always true, and so never use the contents of the module header), all the missing stuff suddenly shows up, because now my qrhi.h and such are correctly part of the precompiled header and the \fn and similar starts working.
As an example, below is a screenshot of the docs generated with the hack inplace, whereas out of the box the functions striked out in red are all missing! (because they are inline functions in qrhi.h, documented with \fn in rhi.cpp, but qrhi.h is not "seen" at all due to the pch logic)
Not sure how this should be handled (build system changes to also generate a new, extended module include? special case certain headers categories within qdoc?) but a solution is pretty much requirede before QTBUG-113331 can progress.
Attachments
Issue Links
- blocks
-
QTBUG-113331 Enable QRhi API usage in applications and libraries without forcing purely private APIs on them
-
- Closed
-