Akira Yokosawa <akiyks@xxxxxxxxx> writes: > > That message of mine just pointed out that the Sphinx bug of false > duplicate C declaration warning first reported by Mauro (+CC'd) at: > https://github.com/sphinx-doc/sphinx/issues/8241 -- > "C domain issues when building the Linux Kernel documentation". > It had not been resolved despite Mauro's recognition of the issue at the > time. > > It was closed without fixing the bug but delegate the issue to an earlier > one of the same nature at: https://github.com/sphinx-doc/sphinx/issues/7819 -- > "C, distinguish between ordinary identifiers and tag names", which was > opened on Jun 12, 2020 and has not been resolved. (almost 4 years ago!) > > There is two pull requests attempting to resolve the issue at: > https://github.com/sphinx-doc/sphinx/pull/8313 -- > "C, distinguish between tag names and ordinary names" and > https://github.com/sphinx-doc/sphinx/pull/8929 -- > "Intersphinx delegation to domains". > PR #8313 needs #8929 as its prerequisite. > > Unfortunately, both PRs are still open as well as the issue #7819. > Honestly speaking, I don't have any idea what prevents those pulls, > give or take the need of rebasing with conflict resolution. > >> So by changing the >> function name to something like "query_drm_format_info(u32 format)" is >> a possible fix. Question is what should I rename this function to, that >> aligns with the coding standards? Also suggest a new function name for >> "drm_modeset_lock" that causes the second warning. > > So, I would rather not rename valid identifiers for the sake of working > around a bug of Sphinx. Rather, I'd appreciate if you'd send a message > encouraging Sphinx devs to resolve the issue sooner rather than later. > > Thanks, Akira Agreed, we should try and get the bug resolved in Sphinx. This same issue came up in relation to this PR that I am working on so hopefully we can work together to get fixes merged upstream: https://github.com/sphinx-doc/sphinx/pull/12162 Thanks, Donald.
