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

2021 rustdoc INVALID_RUST_CODEBLOCKS "breakage" #89135

Closed
Mark-Simulacrum opened this issue Sep 21, 2021 · 4 comments
Closed

2021 rustdoc INVALID_RUST_CODEBLOCKS "breakage" #89135

Mark-Simulacrum opened this issue Sep 21, 2021 · 4 comments
Assignees
Labels
A-edition-2021 Area: The 2021 edition C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Milestone

Comments

@Mark-Simulacrum
Copy link
Member

rustdoc currently has a warn-by-default lint, rustdoc::invalid_rust_codeblocks, which is intended to tell users when rustdoc sees a Rust language code block which is not valid Rust. However, this lint seems to have always been pretty broken: it only attempted to tokenize the input, not actually parse it into a Rust program. So in most cases before almost any text passed in would've not triggered the lint (e.g., the code blocks on this page -- which are clearly not valid Rust -- do not: https://doc.rust-lang.org/1.55.0/nightly-rustc/rustc_metadata/dependency_format/index.html).

However, with the 2021 edition, we have reserved ~any prefix in strings (foo'bar, for example), which causes this lint to fire on quite a lot of this previously accepted Rust code. This is not technically a breaking change -- the lint is warn by default, and is just a lint -- but in practice I worry that the perception will be quite a lot of breakage. The compiler hit quite a few cases in the migration, which all had to be fixed manually -- no rust fix exists here, and can't easily be added I suspect.

@Mark-Simulacrum Mark-Simulacrum added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. A-edition-2021 Area: The 2021 edition labels Sep 21, 2021
@Mark-Simulacrum Mark-Simulacrum added this to the 1.56.0 milestone Sep 21, 2021
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Sep 21, 2021
@camelid
Copy link
Member

camelid commented Sep 21, 2021

cc @rust-lang/rustdoc

We should decide on a plan of action here. (There's more discussion on Zulip.)

@jyn514
Copy link
Member

jyn514 commented Sep 21, 2021

@jyn514 jyn514 self-assigned this Sep 26, 2021
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 28, 2021
…Gomez

Use the correct edition for syntax highlighting doctests

Previously it would unconditionally use edition 2015, which was incorrect.

Helps with rust-lang#89135 in that you can now override the doctest to be 2018 edition instead of being forced to fix the error. This doesn't resolve any of the deeper problems that rustdoc disagrees with most rust users on what a code block is.

cc `@Mark-Simulacrum`
ehuss pushed a commit to ehuss/rust that referenced this issue Oct 4, 2021
…Gomez

Use the correct edition for syntax highlighting doctests

Previously it would unconditionally use edition 2015, which was incorrect.

Helps with rust-lang#89135 in that you can now override the doctest to be 2018 edition instead of being forced to fix the error. This doesn't resolve any of the deeper problems that rustdoc disagrees with most rust users on what a code block is.

cc `@Mark-Simulacrum`
@GuillaumeGomez
Copy link
Member

Can we close this issue now that #89277? Otherwise, what remains to be done?

@Mark-Simulacrum
Copy link
Member Author

Yes, looks like the beta backport is also in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-edition-2021 Area: The 2021 edition C-bug Category: This is a bug. 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

4 participants