-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
unescaped quotation marks in macro-processed doc comments #27489
Comments
Discovered by @birkenfeld |
Definitely seems like #26777 broke pretty printing. Important to note that escaping the quotes would do nothing in a raw string anyway, i.e: #[doc = r" \"It must be Thursday\", said Arthur."] is still invalid. A short term fix is to bump up the delimiter count in the /// Hello "world"#
would become: #[doc = r#" Hello "world"#"#] Maybe Not sure if this would break something else though considering |
Oops, I forgot that I think a workaround to deal with this would be to increase the number of #[doc = r#" Returns the answer"#] // Successive `#`s == 0, use r#"literal"#
#[doc = r#" "It must be Thursday", said Arthur."#] // Successive `#`s == 0, also use r#"literal"#
#[doc = r###" Ruin everything with "## already "###] // Successive `#`s == 2, use r###"literal"### Any better ideas? |
Also, not directly related to this issue, but is the leading space in the doc string intentional? It seems that the space in the original doc comment ( |
Sounds like a good solution to me. As for the leading spaces, I don't think a single space has any significance outside of pretty printing, but obviously leading whitespace in general is significant for markdown formatting. |
Any documentation comments that contain raw-string-looking sequences may pretty-print invalid code when expanding them, as the current logic always uses the `r"literal"` form, without appending any `#`s. This commit calculates the minimum number of `#`s required to wrap a comment correctly and appends `#`s appropriately. Fixes rust-lang#27489.
…nikomatsakis Any documentation comments that contain raw-string-looking sequences may pretty-print invalid code when expanding them, as the current logic always uses the `r"literal"` form, without appending any `#`s. This commit calculates the minimum number of `#`s required to wrap a comment correctly and appends `#`s appropriately. Fixes rust-lang#27489.
It seems like one of the recent fix to macro handling of doc comments (perhaps this) was a bit overzealous in not parsing the string, so that embedded quotation marks don't get escaped. It doesn't show up unless
stringify!
is called, but then it shows invalid code.Compare the behavior of this playpen on nightly vs beta/std (ignoring the initial slashes which are due to #23812 and already fixed).
The text was updated successfully, but these errors were encountered: