I was not here 21 years ago when it was introduced [1], but according to the commit message it was introduced to find leftover Latex mardown.

It tries to find 4 patterns in Sphinx node text (not in raw rst files):

::(?=[^=])|            # two :: (but NOT ::=)

This one has ~100 false positive in susp-ignored.csv (pypi classifiers, slices, ipv6, ...) 

:[a-zA-Z][a-zA-Z0-9]+| # :foo

This one has ~300 false positive in susp-ignored.csv (slices, C:\, ipv6, ...)


`|                     # ` (seldom used by itself)

This one has ~20 false positive in susp-ignored.csv (mostly reStructuredText in code-blocks)

(?<!\.)\.\.[ \t]*\w+:  # .. foo: (but NOT ... else:)

This one does not have false positives.

The script, on my laptop (with a core i9), is slow (4mn20s), and it's probably way slower on the CI.

I tried to search for `suspicious is:pr in:comments` on github to see if it's usefull:

- 2 contributor had an issue with the script (gh-9748, gh-21940)
- 5 had to add false positive to susp-ignored.csv (gh-20556, gh-13772, gh-11481, gh-9317, gh-6915)
- 4 had to update susp-ignored.csv (gh-11769, gh-5552, gh-3694, gh-2719)
- 1 did not addedd to susp-ignored but changed to avoid a false positive (gh-18939)

Case where it actually helped:

- Finding an error: (gh-12562 .. literalinclude: instead of .. literalinclude::)
- Finding refs in code block (gh-7413)
- Writing plaintext in Misc/NEWS (gh-1339)

I'd go for enhancing rstlint.py (which is fast, ~1s on my laptop) a bit to try to handle the `.. literalinclude:` missing a `:` errors, and dropping suspicious.

So I'd appreciate feedback on this script, did it helped you recently?

1: https://github.com/python/cpython/commit/700cf28f410521066f40671f1da7db0302d753fd

I would love to see this disappear.  For me, it has been a recurring time waster.

If it still does useful checks, we could just limit it to running by release managers during the release manufacturing process; it is already run then. It would still allow for problems to be caught and fixed by the RM prior to release tagging.  But I don't have a strong opinion about its overall usefulness. I recall it catching at least one problem in a release I was involved with and that was probably before we had the CI checks.

Good idea Ned!

So proposed plan:

- Drop it from docs build and the CI to avoid time loss.
- Add it as a step of PEP 101, for a few release, for good measures
- I'll check it from time to time between releases, just to ensure it does not accumulate tons of things to do on the the release day.

If during a few release, we notice this tool is no loger usefull we'll be able to drop it.

If we spot some errors that can be migrated to the rstlint.py we'll do.

If this tool is in fact usefull, we'll have to think about it again.

New changeset c9c6e9f89aa68ce8094393a1a5575b67d26bc8c8 by Julien Palard in branch 'master':
bpo-42238: Doc: Remove make suspicious from the CI and docs builds. (GH-23313)
https://github.com/python/cpython/commit/c9c6e9f89aa68ce8094393a1a5575b67d26bc8c8

I'll try to track this closely, the drop of `make suspicious` has been merged in master, but not backported yet, one week ago.

Up to today, no commit has introduced suspicious warnings (0 false positive, 0 false negative).

I think I'll soon backport the PR, if no one objects, because the current situation is a bit risky: some PR could get merged to master but fail the tests during the backport.

Today I spotted one error that suspicious could have spotted:

    -both ``Callable``s no longer validate their ``argtypes``, in 
    +both ``Callable``\ s no longer validate their ``argtypes``, in 

I'm fixing it in https://github.com/python/cpython/pull/23800 

`make suspicious` found it as:

    [whatsnew/changelog:23] "`" found in "Callable``s no longer validate their ``argtypes"

So I'll doodle around this to see if tools/rstlint.py or Sphinx itself can see the error.

I created https://github.com/python/cpython/pull/23802 with a port of the "wrong backtick detector" (at least, one aspect from it) from suspicious to rstlint.

I dropped the suspicious check three weeks ago, and found a single committed issue since then, which was fixable (and is fixed) in rstlint, so I'll continue this experience and see where it goes.

New changeset b9735420aa8ecd2555fe3dc000863bc50487334b by Julien Palard in branch 'master':
bpo-42238: Check Misc/NEWS.d/next/ for reStructuredText issues. (GH-23802)
https://github.com/python/cpython/commit/b9735420aa8ecd2555fe3dc000863bc50487334b

Pablo reenabled the check:

commit 20ac34772aa9805ccbf082e700f2b033291ff5d2 (upstream/master, master)
Author: Pablo Galindo <Pablogsal@gmail.com>
Date:   Mon Apr 12 20:53:15 2021 +0100

    Fix Sphinx errors in the documentation and re-activate the suspicious check (GH-25368)
    
    The suspicious check is still executed as part of the release process and release managers have been
    lately fixing some actual errors that the suspicious target can find. For this reason, reactivate the suspicious
    until we decide what to do in a coordinated fashion.

Background on why I reactivated it:

I every single alpha release I had to fix actual documentation errors (no false positives) like the one fixed here:

https://github.com/python/cpython/commit/20ac34772aa9805ccbf082e700f2b033291ff5d2

I don't like the check, but the release management team don't like to have to restart the release process just fo fix a bunch of docs issues that should have been detected by the CI.

If we remove the fix, we need to coordinate all together because currently the status quo is that the RM team now is responsable of fixing the documentation errors as there are several release tools (and other ones) that depend on this target passing.

If reactivated, the tool needs to be substantially improved.  It is NOT smart.  The false positives for slicing and logging examples are unnecessarily annoying.  It creates a barrier for people submitting documentation patches.  Each of the 367 entries in the susp-ignored file represents wasted time for contributors.

Also the CSV format is arcane, hard-to-read, and hard-to-edit.  It looks like it was quickly thrown together by someone who didn't care about usability.  Perhaps there should be a simpler tools that says, "take this current failure and mark it as a false positive" without trying to be over specific.

Mandatory checks with a high false positive rate are an anti-pattern for CI systems.  Already we've had one case of a contributor (me) who abandoned a doc patch rather than fight this tooling.

I agree with all you said, but I am against forcing the release management team to absorb the responsibility of fixing all the errors that the CI didn't catch, real or not. Releasing is already a multi-hour process and having many docs errors and formating mistakes to fix is a toll that should be paid at release time.

Pablo: "I every single alpha release I had to fix actual documentation errors (no false positives)"

I don't get it. Do you mean that the Python release process is blocked by typos in the documentation? Why did you catch them in the release process, and not in the regular Python development workflow?

Can't we get the same errors in the regular workflow?

I understand that the release process requires no warning from "make suspicious", but as explained in other comments, this tool is not reliable. While it catchs some real bugs, the cost of false positives is too high.

Doc/tools/susp-ignored.csv contains 368 lines, IMO it's a sign that this tool either requires a serious reworking, or must be disabled/removed.

Doc/tools/extensions/suspicious.py is a CPython specific extension, it's not part of Sphinx. Maybe someone should open a feature request on Sphinx to get a similar feature without false positives (or at least less false positives).

> Why did you catch them in the release process, and not in the regular Python development workflow?

Because our release tools run suspicious.py and it fails and then we need to manually inspect every single failure and fix it as almost all times there are real positives among them

> Can't we get the same errors in the regular workflow?

That's what I did reactivating suspicious.py


> I understand that the release process requires no warning from "make suspicious", but as explained in other comments, this tool is not reliable. While it catchs some real bugs, the cost of false positives is too high


Sure, we all agree here. Where it seems that we don't agree is how to proceed. I would be super happy to remove the tool if is agreed everywhere, including with the rest of release managers.

Julien Palard is working actively on the Python documentation. He is the one who removed suspicious "from the CI and docs builds". I trust his judgment here. I suggest to remove it again from there *and* from the release scripts.

I wrote a PR to enhance -W option documentation. The suspicious job complains whereas my Sphinx format is valid:

   The full form of argument is::

       action:message:category:module:lineno

Example of suspicious error:

[using/cmdline:438] ":message" found in "action:message:category:module:lineno"

I see that Doc/tools/suspicious.csv already contains an ignore rule for Doc/using/cmdline.rst.

> Doc/tools/extensions/suspicious.py is a CPython specific extension, it's not part of Sphinx. Maybe someone should open a feature request on Sphinx to get a similar feature without false positives (or at least less false positives).

This extension was written by Gabriel Genellina in 2009 when he discovered that:

   Several documents contain invalid reST markup that "leaks"
   into the html output (missing ``, incorrect indentation, etc.)

Extension added in bpo-4811 with:

commit 700cf28f410521066f40671f1da7db0302d753fd
Author: Georg Brandl <georg@python.org>
Date:   Sun Jan 4 10:23:49 2009 +0000

    Add "suspicious" builder which finds leftover markup in the HTML files.
    
    Patch by Gabriel Genellina.


The code didn't evolved much since it was added in 2009. Main changes.

commit 144c269cc8b82ab3b877797e1c7c26b0849e2b56
Author: Ezio Melotti <ezio.melotti@gmail.com>
Date:   Thu Mar 28 18:01:11 2013 +0200

    Update the suspicious builder to detect unused rules, and remove currently unusued rules.

bpo-22537:

commit 14b5a4da2732d3464c6b40527458005ccf19f95c
Author: Georg Brandl <georg@python.org>
Date:   Thu Oct 2 08:26:26 2014 +0200

    Closes #22537: Make sphinx extensions compatible with Python 2 or 3, like in the 3.x branches

Filename renamed:

* master: Doc/tools/extensions/suspicious.py
* Commit 160cbce92adc3ccbe4ae6e231ea27fb5ff28dca9 renames Doc/tools/suspicious.py to Doc/tools/extensions/suspicious.py
* Commit f16fbf940fdaec594eb1f4c5f9c61e926db53c5d renames Doc/tools/sphinxext/suspicious.py to  Doc/tools/suspicious.py

I should have monitored this more closely, I started monitoring it weekly, then life got over until today when I'm even surprised to see activity on the issue, sry!

(Surprise leading me to investigate why I had not received notifications from bpo, leading me to a bug in my sieve filter...)

I counted, during your releases `make suspicious` spotted:

- 1 true positive in 20ac34772aa9805ccbf082e700f2b033291ff5d2
- 1 false positive in 20ac34772aa9805ccbf082e700f2b033291ff5d2
- 1 true positive in 57f21db3f629649dbd7c4531078b6a2104896411
- 1 false positive in de833b601319da15d90c8f3cd3c44d239d6d5924

if I missed none, the success ratio is not good (which is already known).

What I'm aiming to do in this issue is to list the true positives over time, by passing the tool manually from time to time, to try to see what kind of rule is usefull in such a tool, and ultimately try to spot those errors in a reliable way.

I'd go for removing it from both release process and the CI, this would lower pressure on RMs and contributors, while easing the study of the tool in this issue.

I even consider removing it from the Makefile / tools hierarchy to ensure nobody runs it, because if someone run it locally during its contribution process it may hide true positives from me (leading me to think there's no true positives and the tool is useless).

At least, I would suggest to remove it from the release process.

If some people working on the documentation want to keep the tool, maybe it can be an optional CI job? IMO the problem is that currently, it's part of a single "Documentation" job. I don't recall if it's mandatory or not. Also, we need maybe more explanation in the CI job result how to mark false positives.

New changeset 227a09325e7bf82ecd303b4696c054a086b29a00 by Julien Palard in branch 'main':
bpo-42238: Doc CI: Disable suspicious checks. (GH-26575)
https://github.com/python/cpython/commit/227a09325e7bf82ecd303b4696c054a086b29a00

Spotted a true positive in b19f45533942e4ad7ddf9d2d94f8b87c6f746bce:

    :const:``None``

(I'm trying to build a true positive list, to have usefull cases where suspicious is usefull, so in the long term I can maybe implement those cases in rslint instead.)

The previous one could probably be implemented in rstlint using (an equivalent of):

    git grep ':[a-z]\+:``[^:` ]+``' Doc/

Maybe specialized to known roles, like the script specializes to known directives.

Another true positive:

    ... versionchanged:: 3.11

from : 6cb145d23f5cf69b6d7414877d142747cd3d134c / https://github.com/python/cpython/pull/26820

I also think it can be implemented in rstlint.

New changeset 01331f1a3cf86fd308e9a134bb867bf01fb191f5 by Julien Palard in branch 'main':
bpo-42238: rstlint: Add two new checks. (GH-26966)
https://github.com/python/cpython/commit/01331f1a3cf86fd308e9a134bb867bf01fb191f5

Another one \o/

Fix in: https://github.com/python/cpython/pull/27238

It is:

    :func:pdb.main

Detected by make suspicious as:

    WARNING: [whatsnew/changelog:320] ":func" found in ": Refactor argument processing in :func:pdb.main to simplify"
    WARNING: [whatsnew/changelog:320] ":pdb" found in ": Refactor argument processing in :func:pdb.main to simplify"

I added a test in the same PR to spot this one in rstlint.

New changeset fbf10080bb369cfef1f230c2cd5135a558b242d5 by Julien Palard in branch 'main':
bpo-42238: Fix small rst issue in NEWS.d/. (#27238)
https://github.com/python/cpython/commit/fbf10080bb369cfef1f230c2cd5135a558b242d5

10 false positives today, see: https://github.com/python/cpython/pull/27945/files

I think I now need to put a deadline on this issue, let's say: one year without true positives and I drop it, so 2021-07-19 for now.

(In the meantime, I continue to convert each true positives to rstlint, I converted 3 of them so far.)

New changeset 21fa8547921d28b80b8a88d034081cab000d5480 by Julien Palard in branch 'main':
bpo-42238: [doc] Some more make suspicious false positives. (GH-27945)
https://github.com/python/cpython/commit/21fa8547921d28b80b8a88d034081cab000d5480

New changeset 37272f5800ee1e9fcb2da4a1766366519b9b3d94 by Julien Palard in branch 'main':
bpo-42238: [doc] remove unused, and deduplicate, suspicious ignore rules. (GH-28137)
https://github.com/python/cpython/commit/37272f5800ee1e9fcb2da4a1766366519b9b3d94

New suspicious today:

    [library/typing:1011] "`" found in "        # Type of ``val`` is narrowed to ``list[str]``."

But it's only because the old one with List[str] instead of list[str] was in susp-ignored.csv, so I just fixed susp-ignored.csv in https://github.com/python/cpython/pull/28827.

DING DING DING DING DING DING, a new one today, and a true positive for `make suspicious`, fixed in:

https://github.com/python/cpython/pull/28988/files

(along with the test added to rstlint)

A new false positive today from 31b3a70edb1216bdc8fab3b2eafd8ddb00487f41:

https://docs.python.org/dev/reference/datamodel.html#class-getitem-versus-getitem

in:

    should be called::

        from inspect import isclass

        def subscribe(obj, x):
            """Return the result of the expression `obj[x]`"""

make suspicious whines about the backticks.

New changeset d32316a2aacc3b3c4f6f56f96edb09a4437c8bdb by Julien Palard in branch 'main':
bpo-42238: [doc]: Hide false positive in make suspicious. (GH-29636)
https://github.com/python/cpython/commit/d32316a2aacc3b3c4f6f56f96edb09a4437c8bdb

/!\ rstlint did triggered some false positive: https://github.com/python/cpython/pull/29389/commits/f8ea20a0b51711b1c352c4aa4663cb953e7ebdc8

New changeset 024209401ebc8a011f242af00efdd8ecece6953d by Julien Palard in branch 'main':
bpo-42238: [doc] Announce the future removal of make suspicous. (GH-29652)
https://github.com/python/cpython/commit/024209401ebc8a011f242af00efdd8ecece6953d

A new false positive in b48ac6fe38b2fca9963b097c04cdecfc6083104e:

    +++ b/Misc/NEWS.d/next/Tests/2021-11-23-12-36-21.bpo-45878.eOs_Mp.rst
    @@ -0,0 +1,2 @@
    +Test ``Lib/ctypes/test/test_functions.py::test_mro`` now uses
    +``self.assertRaises`` instead of ``try/except``.

It's been only one month since the last true positive, so I'll still watching this closely...

Another true positive for make suspicious:

    WARNING: [c-api/apiabiversion:70] ":macro" found in "the same format as the c:macro:"

I'm working on implementing it on rstlint, in the meantime I opened:

=> https://github.com/python/cpython/pull/30149

to fix this occurrence. This show that the current version of rstlint catches two mores \o/

I slowly started to work on rstlint in its own tree because working in a single file felt inconfortable.

The more I advanced in this direction the more it made sense to me:

- I first added tests, I may have been able to do so in the cpython tree though.
- It would ease the publication of it to pypi.org so it can be used by other projects.
- It may ease contributions (some non-core-devs could be given rights to the repo, which make sense as it's not really Python related but more Sphinx related).

It currently looks like this: https://github.com/JulienPalard/sphinxlint but should obviously be moved to github.com/python/ if we adopt this direction.

So what do you think? (cc Georg as the main author of the script)

If so I'd also like to rename the thing, it's currently named `rstlint`, but it's more a `sphinxlint` as Sphinx has adds a lot to rst and existing rst linters does not handle Sphinx well.

> I was not here 21 years ago when it was introduced

You gave me a small shock, but I checked and it was only 11/12 years ago :D

I'm fine with moving this out of tree; please coordinate with the Sphinx maintainers whether it should be an "official" extension or completely separate.

IMO moving this small script into the separated project https://github.com/JulienPalard/sphinxlint will help people who are not core developers to contribute and it makes the tool usable by projects outside CPython. So yeah, it's a good thing!

Also, it's more convenient to add tests, put it on PyPI, etc.

> It currently looks like this: https://github.com/JulienPalard/sphinxlint but should obviously be moved to github.com/python/ if we adopt this direction.

If you want to move the project under the https://github.com/psf/ organization, the PSF has some rules to move a project in the Python organization. For example, contributors must respect the PSF Code of Conduct and the GitHub project must have at least 3 administrators. I forgot when I read these rule exactly. See for example https://github.com/psf/pyperf/

* https://github.com/psf/pyperf/blob/main/CODE_OF_CONDUCT.md
* README says "The pyperf project is covered by the PSF Code of Conduct."

New changeset 44afdbd5af4503e376148e9404b9c7a4f595b1fe by Julien Palard in branch 'main':
bpo-42238: [doc] Avoid hardcoding fast-moving lines in susp-ignored.csv. (GH-30981)
https://github.com/python/cpython/commit/44afdbd5af4503e376148e9404b9c7a4f595b1fe

> You gave me a small shock, but I checked and it was only 11/12 years ago :D

HAha! Either I misstyped 12 as 21, either I'm bad at math, sorry for the shock ;)

> I'm fine with moving this out of tree; please coordinate with the Sphinx maintainers whether it should be an "official" extension or completely separate.

They propose [1] to have it in sphinx-contrib ("A collection of Sphinx extensions maintained by their respective authors. It is not an official part of Sphinx."), what do you think?

[1] https://github.com/sphinx-doc/sphinx/issues/10143#issuecomment-1025093280

Sure!

OK, we have: https://github.com/sphinx-contrib/sphinx-lint

Ping me if you want rights :)

Georg, I was able to move forward:

- https://github.com/sphinx-contrib/sphinx-lint
- https://pypi.org/project/sphinx-lint/

Does everything looks good to you?

Next step would be to remove rstlint.py from Docs/tools and add a dependency to rstlint from the Makefile (for make check), so the CI uses sphinx-lint.

Looks good. I should have rights automatically for everything in that org.

> https://pypi.org/project/sphinx-lint/

Congrats :-)

New changeset b878b3af0b3a9e3ab3ffcaf90a4066dfb3bb7cac by Julien Palard in branch 'main':
bpo-42238: [doc] moving from rstlint.py to sphinx-lint. (GH-31097)
https://github.com/python/cpython/commit/b878b3af0b3a9e3ab3ffcaf90a4066dfb3bb7cac

News: 

Hitting 3 months without a true positive from `make suspicious`, looks like sphinxlint starting to take over properly, I hope to close this issue soon (like in a few months maybe).

Also sphinxlint attracted some contributors [1] \o/

[1] https://github.com/sphinx-contrib/sphinx-lint

New changeset ec8906fb5930b1f078e2a2170cdf445e6c6faf57 by Julien Palard in branch 'main':
bpo-42238: [doc] Some lines moved in rst, but had hardcoded lineno in susp-ignored.csv. (GH-32070)
https://github.com/python/cpython/commit/ec8906fb5930b1f078e2a2170cdf445e6c6faf57

One true positive and one false positive this week, see: 

- 7f9c084fdec7ddcfe8855aa79f98545591ae2261
- ec8906fb5930b1f078e2a2170cdf445e6c6faf57

New changeset bdc497496548e30fa208a8d98c30bf6d1833ac4c by Julien Palard in branch 'main':
bpo-42238: [doc]: make suspicious: false positive. (GH-32292)
https://github.com/python/cpython/commit/bdc497496548e30fa208a8d98c30bf6d1833ac4c

New changeset d0e696e05d4aaca1f1cde72a5c3326ca3d0f5c24 by Julien Palard in branch 'main':
bpo-42238: [doc]: A make sucpicious false positive. (GH-32329)
https://github.com/python/cpython/commit/d0e696e05d4aaca1f1cde72a5c3326ca3d0f5c24

One true positive today: https://github.com/python/cpython/pull/32355