Message ID | c758b45282f8eb5fec401da6021d7ded6cebb243.1717564310.git.ps@pks.im (mailing list archive) |
---|---|
State | Accepted |
Commit | f60fec6a1665891e50b94ff553b4165fe8ab3f2d |
Headers | show |
Series | Documentation: improve linting of manpage existence | expand |
Patrick Steinhardt <ps@pks.im> writes: > These escape sequences seem to be part of Asciidoc itself. In the long > term, we should probably consider dropping support for Asciidoc in favor > of Asciidoctor. Upstream also considers itself to be legacy software and > recommends to move away from it [2]: > ... > For now though, let's expand its lifetime a little bit more by filtering > out these new warnings. We should probably reconsider once the warnings > are upgraded to errors by Python. Sounds sensible. We can throw it in to the Git 3.0 list, perhaps ;-)
diff --git a/ci/test-documentation.sh b/ci/test-documentation.sh index de41888430..02b3af3941 100755 --- a/ci/test-documentation.sh +++ b/ci/test-documentation.sh @@ -11,6 +11,7 @@ filter_log () { -e '/^ \* new asciidoc flags$/d' \ -e '/stripped namespace before processing/d' \ -e '/Attributed.*IDs for element/d' \ + -e '/SyntaxWarning: invalid escape sequence/d' \ "$1" }
In Python 3.6, unrecognized escape sequences in regular expressions started to produce a DeprecationWarning [1]. In Python 3.12, this was upgraded to a SyntaxWarning and will eventually be raised even further to a SyntaxError. We indirectly hit such unrecognized escape sequences via Asciidoc, which results in a bunch of warnings: $ asciidoc -o /dev/null git-cat-file.txt <unknown>:1: SyntaxWarning: invalid escape sequence '\S' <unknown>:1: SyntaxWarning: invalid escape sequence '\S' This in turn causes our "ci/test-documentation.sh" script to fail, as it checks that stderr of `make doc` is empty. These escape sequences seem to be part of Asciidoc itself. In the long term, we should probably consider dropping support for Asciidoc in favor of Asciidoctor. Upstream also considers itself to be legacy software and recommends to move away from it [2]: It is suggested that unless you specifically require the AsciiDoc.py toolchain, you should find a processor that handles the modern AsciiDoc syntax. For now though, let's expand its lifetime a little bit more by filtering out these new warnings. We should probably reconsider once the warnings are upgraded to errors by Python. [1]: https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals [2]: https://github.com/asciidoc-py/asciidoc-py/blob/6d9f76cff0dc3b7ca21bdd570200f8518464d99b/README.md#asciidocpy Signed-off-by: Patrick Steinhardt <ps@pks.im> --- ci/test-documentation.sh | 1 + 1 file changed, 1 insertion(+)