-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
ASCII color codes are displayed inline for for editors #15443
Comments
I think the derive macro is emitting escape codes (when using a stable compiler): https://github.com/SergioBenitez/proc-macro2-diagnostics/blob/master/src/line.rs#L79 |
Ah good catch, that's indeed gonna be the issue. There isn't really anything we can do here then, r-a just spits out the error messages we get in json verbatim as the expectation is for compiler diagnostics to be just text. This might be something to request as a feature for the proc-macro api, since the compiler itself has a flag that toggles whether the json output has colors in it or not which this should hook into. |
Ah, there it is! Thanks so much for identifying the real culprit for me! I'll continue my hunt over there. |
Interestingly, it seems like Here's what it looks like in my terminal, and the color codes are not printed! It seems like proc-macro do attempt to use different logic depending on whether or not
@Veykril, you mentioned "the error messages we get in json". It seems like What field do you render? Is it The full JSON object
{
"reason": "compiler-message",
"package_id": "foo 0.1.0 (path+file:///home/andreas/tmp/foo)",
"manifest_path": "/home/andreas/tmp/foo/Cargo.toml",
"target": {
"kind": [
"bin"
],
"crate_types": [
"bin"
],
"name": "foo",
"src_path": "/home/andreas/tmp/foo/src/main.rs",
"edition": "2021",
"doc": true,
"doctest": false,
"test": true
},
"message": {
"rendered": "error: [note] error occurred while deriving `UriDisplay`\n --> src/main.rs:7:10\n |\n7 | #[derive(UriDisplayPath)]\n | ^^^^^^^^^^^^^^\n |\n = note: this error originates in the derive macro `UriDisplayPath` (in Nightly builds, run with -Z macro-backtrace for more info)\n\n",
"children": [],
"code": null,
"level": "error",
"message": "\u001b[1;34m[\u001b[0m\u001b[1;32mnote\u001b[0m\u001b[1;34m] \u001b[0m\u001b[1;39merror occurred while deriving `UriDisplay`\u001b[0m",
"spans": [
{
"byte_end": 98,
"byte_start": 84,
"column_end": 24,
"column_start": 10,
"expansion": {
"def_site_span": {
"byte_end": 36109,
"byte_start": 36044,
"column_end": 66,
"column_start": 1,
"expansion": null,
"file_name": "/home/andreas/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rocket_codegen-0.5.0-rc.3/src/lib.rs",
"is_primary": false,
"label": null,
"line_end": 1060,
"line_start": 1060,
"suggested_replacement": null,
"suggestion_applicability": null,
"text": [
{
"highlight_end": 66,
"highlight_start": 1,
"text": "pub fn derive_uri_display_path(input: TokenStream) -> TokenStream {"
}
]
},
"macro_decl_name": "#[derive(UriDisplayPath)]",
"span": {
"byte_end": 98,
"byte_start": 84,
"column_end": 24,
"column_start": 10,
"expansion": null,
"file_name": "src/main.rs",
"is_primary": false,
"label": null,
"line_end": 7,
"line_start": 7,
"suggested_replacement": null,
"suggestion_applicability": null,
"text": [
{
"highlight_end": 24,
"highlight_start": 10,
"text": "#[derive(UriDisplayPath)]"
}
]
}
},
"file_name": "src/main.rs",
"is_primary": true,
"label": null,
"line_end": 7,
"line_start": 7,
"suggested_replacement": null,
"suggestion_applicability": null,
"text": [
{
"highlight_end": 24,
"highlight_start": 10,
"text": "#[derive(UriDisplayPath)]"
}
]
}
]
}
} BTW, I notice that EDIT 1: To my surprise, |
No, there is no bug here. The colored
earlier |
What flag is that, if not |
That flag controls the color of the compilers output colors for diagnostic, the color you are seeing here (that is the |
Yes, but proc-macro emits that conditionally on whether or not the |
Yes, that is a feature flag. Passing |
Oh, that's interesting. Any idea how on earth proc-macro is able to distinguish between colorized and plain output then? Because, as you can see in my screenshots, it does not colorize "[note]" when I pipe it to |
Do you have any pointers to how one checks that flag? |
I am sure you are right, I just don't understand. What trips me up here is that |
All, copying my comments from SergioBenitez/proc-macro2-diagnostics#3 (comment) here for discourse:
|
Interesting, so cargo already handles this specially itself as well? In that case you are right, we should do the same as cargo here when processing |
Is there any solution I can avoid this right now? I tried add color=never in my .toml, but it only avoid color output in cargo build, not in diagnostics. Can I setup rust-analyzer or something? |
I know of no work-around until they fix this. |
One "work-around" is to use a nightly toolchain, at least for rust-analyzer. |
Sometimes, the error shown in Vim (and apparently VS Code too) is printed with ASCII color codes showing in the string from rust_analyzer. It makes the error very hard to read. See neovim/nvim-lspconfig#2760.
It seems to me like
rust-analyzer
does not properly distinguish between being executed in a terminal environment or not, and decide from that whether to print ASCII color codes or skip them.In terminal:
In editor:
Steps to reproduce
cargo check
.src/main.rs
with Vim.Other info
rust-analyzer version: (eg. output of "rust-analyzer: Show RA Version" command, accessible in VSCode via Ctrl/⌘+Shift+P)
Mason reports rust-analyzer 2023-08-07.
rustc version: (eg. output of
rustc -V
)relevant settings: (eg. client settings, or environment variables like
CARGO
,RUSTC
,RUSTUP_HOME
orCARGO_HOME
)Not sure, nothing I've set explicitly at least. I run NeoVim with rust-lang/rust.vim and rust_analyzer for lspconfig installed via Mason.
The text was updated successfully, but these errors were encountered: