rustdoc: Take into account edition information for keyword highlighting - #161944
rustdoc: Take into account edition information for keyword highlighting#161944GuillaumeGomez wants to merge 1 commit into
Conversation
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
1a83eb3 to
86c5df9
Compare
This comment has been minimized.
This comment has been minimized.
1e831c0 to
05a128c
Compare
|
Cleaned up all my mess. Ready for review. |
There was a problem hiding this comment.
Isn't source-code-pages/ for testing the contents of source code pages *.rs.html only? Here however, we're testing how the code blocks are rendered on "API pages", aren't we?
IIRC this belongs into tests/rustdoc-html/doctest/.
| &code, | ||
| None, | ||
| None, | ||
| original_span.edition(), |
There was a problem hiding this comment.
Could you add a // NOTE: here that states that this is only "an approximation" or "best effort" since the edition of individual tokens contained in the expansion can differ from the "overarching edition" / the edition of the entire expansion (original_span.edition()).
And we can't fix that since code is just a String that was produced by rustc_ast_pretty meaning more precise edition information has been lost.
To give an example:
//@ edition: 2015
#[macro_export]
macro_rules! generate {
($kw:ident) => {
pub fn host() {
let _ = $kw {};
}
};
}//@ edition: 2024
dependency::generate!(async);Here, your PR doesn't highlight the async in the rendered expansion … let _ = async {} … since it uses the edition of the entire expansion (which is Rust 2015) but the async in the Rust 2015 expansion does actually refer to Rust 2024 keyword async and thus contains an async block, not a struct expression! That's because the keyword async originates from a Rust 2024 crate (root expansion).1
I think that's perfectly acceptable for now but a NOTE would be nice.
Footnotes
-
Or vice versa: The dependency is Rust 2024 and the dependent is Rust 2015. In such a case, the keyword currently gets highlighted even though it shouldn't be. ↩
fmease
added
S-waiting-on-author
05a128c to
40dc901
Compare
|
Applied suggestions (and mostly took your comment for the note because I think it's more than enough hehe). |
|
@bors r=fmease rollup |
rust-bors
Bot
added
S-waiting-on-bors
…g, r=fmease rustdoc: Take into account edition information for keyword highlighting Fixes rust-lang#148221. The only thing that was missing was passing down an `Edition` to the highlighter (and adding tests). r? @fmease
…g, r=fmease rustdoc: Take into account edition information for keyword highlighting Fixes rust-lang#148221. The only thing that was missing was passing down an `Edition` to the highlighter (and adding tests). r? @fmease
…g, r=fmease rustdoc: Take into account edition information for keyword highlighting Fixes rust-lang#148221. The only thing that was missing was passing down an `Edition` to the highlighter (and adding tests). r? @fmease
… r=fmease Move rustdoc ui doctests into the right testsuite When working on rust-lang#161944 (comment), I realized that a lot of doctests in `rustdoc-html` testsuite were not in the correct testsuite, so moving them in the right location. Because you're the one who made me realize it, here goes @fmease (thanks!) :p r? @fmease
Rollup of 7 pull requests Successful merges: - #160941 (Enforce safety comments on `alloc`) - #161975 (Abort instead of unwinding out of an inconsistent BTreeMap::split_off) - #157968 (Preserve ambiguous glob lint for subtrait method picks) - #161514 (rework handling of doc attributes on macro calls) - #161944 (rustdoc: Take into account edition information for keyword highlighting) - #161974 (remove rustc_never_type_options attr remnants) - #161978 (Move rustdoc ui doctests into the right testsuite) Failed merges: - #161702 (Use `drop_guard` in some places in {core,alloc,std})
4 participants
Fixes #148221.
The only thing that was missing was passing down an
Editionto the highlighter (and adding tests).r? @fmease