All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Adam Turner <aaturnerpython@outlook.com>
Cc: Akira Yokosawa <akiyks@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: Sphinx pre v3 -- removing support
Date: Sat, 2 Jul 2022 12:23:11 +0100	[thread overview]
Message-ID: <20220702122311.358c0219@sal.lan> (raw)
In-Reply-To: <LO3P123MB2681A3F3A05E269AE0351799C2A19@LO3P123MB2681.GBRP123.PROD.OUTLOOK.COM>

Em Fri, 3 Jun 2022 15:27:18 +0000
Adam Turner <aaturnerpython@outlook.com> escreveu:

> >> From Sphinx's perspective, we'd like to remove long-deprecated code.
> >> What is a good solution here for both sides? The intertial option is
> >> for us to delay the deprecation by another major version (removal is
> >> currently scheduled for Sphinx 6 (2023-05), and we are currently 
> >> releasing a major version every May.  
> 
> > So, can we assume that there won't be any backward-incompatible
> > behavior changes in Sphinx due to the removal of those long-deprecated
> > code?  
> 
> I'm referring to removing support for the "c_allow_pre_v3", 
> "c_warn_on_allowed_pre_v3", configuration options [1]_, and the 
> associated support for still parsing the pre v3 syntax in the C 
> domain [2]_. This means that pre v3 syntax in reStructuredText files
> would not work with Sphinx 6 onwards.
> 
> > Or do you mean that after the release of Sphinx 6, pre v3 Sphinx
> > will be removed in the PyPI repository?  
> 
> No releases will be removed from PyPI, but if pre v3 syntax is still
> used, Sphinx 6.0 would fail to properly parse it.

Adam,

Despite the performance issues with Sphinx > 2.x.x, there is another
reason why the default is to use 2.4.4 version. Currently, building
the docs with any version newer than that will cause 11 false-positives
warnings:

	    Documentation/driver-api/usb/usb:164: ./drivers/usb/core/message.c:967: WARNING: Duplicate C declaration, also defined at driver-api/usb/gadget:783.
Declaration is '.. c:function:: int usb_string (struct usb_device *dev, int index, char *buf, size_t size)'.
    Documentation/driver-api/usb/usb.rst:967: WARNING: Duplicate C declaration, also defined at driver-api/usb/gadget:783.
Declaration is '.. c:struct:: usb_string'.
    Documentation/driver-api/miscellaneous:48: ./drivers/pwm/core.c:599: WARNING: Duplicate C declaration, also defined at driver-api/miscellaneous:240.
Declaration is '.. c:function:: int pwm_capture (struct pwm_device *pwm, struct pwm_capture *result, unsigned long timeout)'.
    Documentation/driver-api/surface_aggregator/client-api:25: ./drivers/platform/surface/aggregator/controller.c:1689: WARNING: Duplicate C declaration, also defined at driver-api/surface_aggregator/client-api:105.
Declaration is '.. c:function:: int ssam_request_sync (struct ssam_controller *ctrl, const struct ssam_request *spec, struct ssam_response *rsp)'.
    Documentation/driver-api/80211/mac80211:109: ./include/net/mac80211.h:4933: WARNING: Duplicate C declaration, also defined at driver-api/80211/mac80211:1041.
Declaration is '.. c:function:: void ieee80211_tx_status (struct ieee80211_hw *hw, struct sk_buff *skb)'.
    Documentation/gpu/amdgpu/driver-core:163: ./drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:735: WARNING: Duplicate C declaration, also defined at gpu/amdgpu/driver-core:93.
Declaration is '.. c:function:: void amdgpu_vm_tlb_seq_cb (struct dma_fence *fence, struct dma_fence_cb *cb)'.
    Documentation/gpu/drm-kms:360: ./drivers/gpu/drm/drm_fourcc.c:298: WARNING: Duplicate C declaration, also defined at gpu/drm-kms:36.
Declaration is '.. c:function:: const struct drm_format_info * drm_format_info (u32 format)'.
    Documentation/gpu/drm-kms:459: ./drivers/gpu/drm/drm_modeset_lock.c:392: WARNING: Duplicate C declaration, also defined at gpu/drm-kms:49.
Declaration is '.. c:function:: int drm_modeset_lock (struct drm_modeset_lock *lock, struct drm_modeset_acquire_ctx *ctx)'.
    Documentation/gpu/drm-uapi:357: ./drivers/gpu/drm/drm_ioctl.c:917: WARNING: Duplicate C declaration, also defined at gpu/drm-uapi:70.
Declaration is '.. c:function:: bool drm_ioctl_flags (unsigned int nr, unsigned int *flags)'.
    Documentation/gpu/rfc/i915_scheduler:138: ./include/uapi/drm/i915_drm.h:3: WARNING: Duplicate C declaration, also defined at gpu/driver-uapi:2101.
Declaration is '.. c:struct:: i915_context_engines_parallel_submit'.
    Documentation/gpu/rfc/i915_scheduler.rst:3: WARNING: Duplicate C declaration, also defined at gpu/driver-uapi:2101.
Declaration is '.. c:struct:: i915_context_engines_parallel_submit'.

Basically, on 11 places inside the Kernel we use the same name for
functions and for struct (or enum), as this is perfectly fine on C.

Yet, even having different tags at the C domain after Sphinx 3.x, it
still doesn't place them on separate namespaces. Those are all caused
by this bug, whose fixes are yet to be merged:

	https://github.com/sphinx-doc/sphinx/pull/8313

Is this planned to be solved during Sphinx 5.x development cycle?

Regards,
Mauro

      parent reply	other threads:[~2022-07-02 11:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03 14:13 Sphinx pre v3 -- removing support Adam Turner
2022-06-03 14:21 ` Jonathan Corbet
2022-06-03 14:30   ` Adam Turner
2022-06-03 21:34     ` Jonathan Corbet
2022-06-03 15:22   ` Matthew Wilcox
2022-06-03 15:30     ` Adam Turner
2022-06-03 15:38       ` Matthew Wilcox
2022-06-03 15:42     ` Konstantin Ryabitsev
2022-06-03 16:00       ` Jonathan Corbet
2022-06-03 16:26         ` Konstantin Ryabitsev
2022-06-03 21:50           ` Jonathan Corbet
2022-06-13 15:40             ` Konstantin Ryabitsev
2022-06-13 16:00               ` Matthew Wilcox
2022-06-13 16:16                 ` Adam Turner
2022-06-13 16:19                   ` Matthew Wilcox
2022-06-03 22:11     ` Jonathan Corbet
2022-06-03 15:05 ` Akira Yokosawa
2022-06-03 15:27   ` Adam Turner
2022-06-03 15:44     ` Jani Nikula
2022-06-03 15:54       ` Adam Turner
2022-06-03 16:36         ` Akira Yokosawa
2022-06-03 19:05           ` Jani Nikula
2022-06-04  8:13             ` Mauro Carvalho Chehab
2022-07-02 11:23     ` Mauro Carvalho Chehab [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220702122311.358c0219@sal.lan \
    --to=mchehab@kernel.org \
    --cc=aaturnerpython@outlook.com \
    --cc=akiyks@gmail.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.