Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: Errors during syntax highlighting appear to be fatal #53919

Closed
chrysn opened this issue Sep 3, 2018 · 0 comments
Closed

doc: Errors during syntax highlighting appear to be fatal #53919

chrysn opened this issue Sep 3, 2018 · 0 comments
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@chrysn
Copy link
Contributor

chrysn commented Sep 3, 2018

When building documentation on bindgen-produced Rust files, a possible sight looks like this:

error: unknown start of token: \
 --> <stdin>:8:1
  |
8 | \__________pkt->size___________/          \_result->size_/ \__pkt->size__/                                                
  | ^

warning: Backing out of syntax highlighting
  |
  = note: You probably did not intend to render this as a rust code-block

(Apparently github swallows the output color codes, but envision error in alerting red and warning in yellow).

To the moderately experienced developer, this screams "The build did not succeed", and they might even go as far as to look at how to make rust-bindgen produce more readable comments -- where actually, everything is fine and this is just a warning.

It appears to me that the error output of the highlighter is passed on to stderr. I suggest that the error be visually styled in a way that it can not be mistaken for a fatal error in the build process itself, eg. by replacing the red "error" text with a yellow "syntax highlighter error (caught)", and/or by indenting the output of the syntax highlighter.

I'd be happy to contribute code but failed to find the component that issues the "Backing out of syntax highlighting" messages; pointers would be appreciated.

Meta

  • cargo 1.29.0-nightly (0ec7281b9 2018-08-20)
@GuillaumeGomez GuillaumeGomez added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Sep 3, 2018
bors added a commit that referenced this issue Oct 12, 2018
…tMisdreavus

Improve error display for codeblocks in rustdoc

Part of #53919.

r? @QuietMisdreavus
Centril added a commit to Centril/rust that referenced this issue Jan 15, 2019
…etMisdreavus

rustdoc: overhaul code block lexing errors

Fixes rust-lang#53919.

This PR moves the reporting of code block lexing errors from rendering time to an early pass, so we can use the compiler's error reporting mechanisms. This dramatically improves the diagnostics in this situation: we now de-emphasize the lexing errors as a note under a warning that has a span and suggestion instead of just emitting errors at the top level.

Additionally, this PR generalizes the markdown -> source span calculation function, which should allow other rustdoc warnings to use better spans in the future.

Last, the PR makes sure that the code block is always emitted in the docs, even if it fails to highlight correctly.

Of note:
- The new pass unfortunately adds another pass over the docs to gather the doc blocks for syntax-checking. I wonder if this could be combined with the pass that looks for testable blocks? I'm not familiar with that code, so I don't know how feasible that is.
- `pulldown_cmark` doesn't make it easy to find the spans of the code blocks, so the code that calculates the spans is a little nasty. It works for all the test cases I threw at it, but I wouldn't be surprised if an edge case would break it. Should have a thorough review.
- This PR worsens the state of rust-lang#56885, since those certain fatal lexing errors are now emitted before docs get generated at all.
bors added a commit that referenced this issue Jan 20, 2019
rustdoc: overhaul code block lexing errors

Fixes #53919.

This PR moves the reporting of code block lexing errors from rendering time to an early pass, so we can use the compiler's error reporting mechanisms. This dramatically improves the diagnostics in this situation: we now de-emphasize the lexing errors as a note under a warning that has a span and suggestion instead of just emitting errors at the top level.

Additionally, this PR generalizes the markdown -> source span calculation function, which should allow other rustdoc warnings to use better spans in the future.

Last, the PR makes sure that the code block is always emitted in the docs, even if it fails to highlight correctly.

Of note:
- The new pass unfortunately adds another pass over the docs to gather the doc blocks for syntax-checking. I wonder if this could be combined with the pass that looks for testable blocks? I'm not familiar with that code, so I don't know how feasible that is.
- `pulldown_cmark` doesn't make it easy to find the spans of the code blocks, so the code that calculates the spans is a little nasty. It works for all the test cases I threw at it, but I wouldn't be surprised if an edge case would break it. Should have a thorough review.
- This PR worsens the state of #56885, since those certain fatal lexing errors are now emitted before docs get generated at all.
chrysn added a commit to RIOT-OS/rust-riot-sys that referenced this issue May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants