code blocks without language error with sphinx #3
Comments
|
I tried to reproduce this issue but for me it works. Maybe try again with a new release. Maybe this helps somehow. |
|
Ok, I tried this again. This time I used this as my way of reproducing. First, create a After creating that file we'll do the rest inside a clean docker environment: Inside of the docker container install the requirements and the latest version of rstcheck: Now run the command: I got this error I can probably put together a version of the sphinx docs for you that would trigger this if it would be helpful. Thanks for your help with this. |
|
I also tried it again with a clean venv and I still cannot reproduce. Could you try to clone this repo and then try the procedure with this repo again and run But it would also be good to have your rst source you try to lint. Maybe this will help. |
|
I think you are correct that this has to do with my docs so I'll try to set up a minimal example. But for the record I used this procedure: Inside the container: This worked, telling me that there's something odd in my config that I need to account for. I'll try to get the minimal example together and send that to you. |
|
I found the offending code. It looks like: And it renders like:
When I put that into a file by itself named |
|
The good news is that I can reproduce the issue now. The bad news is that that seems to be an issue known for 7 years and being figured out: What language is the code snippet above? |
|
Well that's a bummer :) It's a query syntax used in AWS CloudWatch Logs for Log-Insights that is similar to SQL. Do you think there is a different kind of block I could use here that wouldn't trigger the exception? |
|
Thanks for the information. That's exactly what I thought too. I guess the error occurs because no language is set for the code block and sphinx tries by default to parse the code as python source code. The solution here is to set the language of the code block to text: .. code:: text
fields @timestamp, @message
| filter @logStream like /imports|proxies/
| filter message like /upload_id:11151/
| sort @timestamp desc
| limit 20 |
|
That's fascinating! Ok, so a simple fix and I'm good to go. Thanks. Is there a rule I could turn on that would warn me if I haven't set the language for a code block? I imagine that's a useful thing for me to enforce in my code. |
|
Unfortunately there is no rule. Maybe in the future when #8 is implemented there may be a way to write a custom rule. I myself am fairly new to the code base and started as maintainer just a week ago. But the deeper I dig the more I see rstchecks limitations. Thats why I am currently working on checking what rstcheck can do and cannot do with rstcheck/rstcheck#97. |
|
Well I super appreciate your efforts to help me here. Thank you so much and good luck with this code base :) |
|
Reopening the issue, because there are more issues with this bug. See rstcheck/rstcheck#121 |
Wrap up of rstcheck/rstcheck#121This issue only occurs when sphinx is involved. .. code:: python
print(
.. code::
print(
This snippet should produce the following output: $ rstcheck test.rst
test.rst:3: (ERROR/3) (python) unexpected EOF while parsingBut instead the error is not found.
|
|
The result from the above wrap-up is the same, regardless of the code directive used: code || code-block || sourcecode. BUT I could observe that the sourcecode directive has a bit of another flow in code and somehow end with the same result. If a code directive has no language defined and sphinx is present, this line in sphinx throws an AttributeError: https://github.com/sphinx-doc/sphinx/blob/4c664ae0b873af91b030a8da253959c0727e1c7a/sphinx/directives/patches.py#L172, when rstcheck runs. When you however build the rst source with sphinx you get normal output in HTMl for example: |
Cielquan
changed the title
|
Started work on |
|
My approach did fix the initial issue, but raised other issues like no longer detecting too short underlining. I am currently investigating if a rstcheck sphinx-builder would be a possible solution to this problem. EDIT: Work on rstcheck sphinx-builder has stopped. |
|
I'm getting this error on a file on a file with no I unfortunately cannot share that file with you (confidential design document), but wanted to raise awareness for this issue. |
Dependabot has updated the version for rstcheck in Documentation/requirements-min/requirements.txt, but it has never been synchronised with Documentation/requirements.txt after that. And as it happens, rstcheck 6.1.1 has had several breaking changes since 3.3.1, and a few updates are necessary: - Option --report has been replaced with --report-level. - Option --ignore-language has been replaced with --ignore-languages. - Option --ignore-message has been replaced with --ignore-messages. - For some reason, the ..openapi directive is now reported as an issue. - It seems that rstcheck is better at analysing code blocks, but this results in many reports for our C blocks (which are not meant to be parsed as standalone snippets), so we skip analysis of C blocks. - But the issue with malformed tables has been fixed and we can remove the ignore on the relevant message. At last, the most annoying thing is that this version has a bug, showing "critical" level messages about AttributeError reports. It mentions that it may be related to code blocks without a language specified, but we don't have these (or are not supposed to), and other people have reported this might also be caused by directives in included text fragments. See the relevant GitHub issue for more details: rstcheck/rstcheck-core#3. At least, these messages do not cause rstcheck to return with an error, so we can deal with them by simply filtering them out. New reports from rstcheck 6.1.1 that we do not want to ignore have been fixed in previous commits. Fixes: cilium#22155 Fixes: a819d97 ("build(deps): bump rstcheck in /Documentation/requirements-min") Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Dependabot has updated the version for rstcheck in Documentation/requirements-min/requirements.txt, but it has never been synchronised with Documentation/requirements.txt after that. And as it happens, rstcheck 6.1.1 has had several breaking changes since 3.3.1, and a few updates are necessary: - Option --report has been replaced with --report-level. - Option --ignore-language has been replaced with --ignore-languages. - Option --ignore-message has been replaced with --ignore-messages. - For some reason, the ..openapi directive is now reported as an issue. - It seems that rstcheck is better at analysing code blocks, but this results in many reports for our C blocks (which are not meant to be parsed as standalone snippets), so we skip analysis of C blocks. - But the issue with malformed tables has been fixed and we can remove the ignore on the relevant message. At last, the most annoying thing is that this version has a bug, showing "critical" level messages about AttributeError reports. It mentions that it may be related to code blocks without a language specified, but we don't have these (or are not supposed to), and other people have reported this might also be caused by directives in included text fragments. See the relevant GitHub issue for more details: rstcheck/rstcheck-core#3. At least, these messages do not cause rstcheck to return with an error, so we can deal with them by simply filtering them out. New reports from rstcheck 6.1.1 that we do not want to ignore have been fixed in previous commits. Fixes: #22155 Fixes: a819d97 ("build(deps): bump rstcheck in /Documentation/requirements-min") Signed-off-by: Quentin Monnet <quentin@isovalent.com>
|
I'm having this issue with files containing https://github.com/ClearcodeHQ/matchbox/blob/main/docs/source/contributing.rst |
|
Code block responsible: https://github.com/rstcheck/rstcheck-core/blob/v1.1.0/src/rstcheck_core/checker.py#L220-L244 If someone finds a solution PRs are welcome. |
I am trying to debug an issue with this tool and tried running with debug. Here's the command I ran:
The traceback looks like:
I am using python 3.9.10:
And my set of packages are:
The error I was looking into has the same shape as the problem in issue #66 . They may be related or this may be something different. This may also be an issue with
docutilsand if you determine I should open the issue there I'm happy to.The text was updated successfully, but these errors were encountered: