-
Notifications
You must be signed in to change notification settings - Fork 1.8k
fix: handle escaped chars in doc comments #17024
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
Conversation
cc @Veykril See #16980 (comment) I'm not sure if this is the best approach to handle escaped chars, but if we store text instead of not storing the string value, then we'll need to unescape it later on, which makes it complex. Hope you can provide some suggestions. |
This won't work, both our mbe parsing and the proc-macro logic expect I don't think having to unescape at call sites should be too bad though, we can have the |
If we unescape characters in |
That's fine, we can return a |
That is, in https://github.com/rust-lang/rust-analyzer/blob/4135696ea7d5b09f30f79676a3795f91610a025d/crates/ide-db/src/documentation.rs there are some calls that care about unescaping and I presume (haven't checked),
|
crates/hir-expand/Cargo.toml
Outdated
@@ -33,6 +33,7 @@ mbe.workspace = true | |||
limit.workspace = true | |||
span.workspace = true | |||
parser.workspace = true | |||
ra-ap-rustc_lexer.workspace = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's re-export the unescape stuff from the parser or syntax crate (reason being that the ra-ap-rustc
crates are special and require extra extern crate
prelude annotations, a re-export saves us from that here
One more annoyance, but otherwise lgtm! Thanks! |
Thanks! |
☀️ Test successful - checks-actions |
fix #16980.
For
ast::LiteralKind::String
, store the original string value.