Closed makoConstruct closed 1 year ago
(the reason I didn't file this via the 'bug' option was, It wasn't initially clear to me that this was a bug, I thought I might be writing up more of a feature request, only learned later that the feature is already implemented and working for most people.)
Can you show an example / screenshot of what you mean?
So in this case, my question would be, well, what types? Please tell me. But this inline box will not show enough information, and I'll have to resort to messing around with the terminal.
What rustc version are you using? Could you reproduce the problem with a small example in a new project?
I think this is kind of expected since we split diagnostic sub-spans up into linked diagnostics (which have terrible UX in VSCode), so the expected foo, found bar
part is in a different diagnostic on the same text range (Note the 1 of 3 problems
part in the pop-up).
we split diagnostic sub-spans up into linked diagnostics (which have terrible UX in VSCode)
What UX? There isn't a way here to get it to show the other diagnostic spans. Clicking the arrows doesn't do that, it goes between 'problems', none of which show the rest of the error. The number in 1 of 3 problems
tracks with the number of problem sites across the whole file. There are no relevant actions in the action search relating to 'diagnostics'.
What rustc version are you using? Could you reproduce the problem with a small example in a new project?
rustc 1.63.0-nightly (42e1761c7 2022-05-15). The problem is present in every project I've opened vscode on, including the projects of people who aren't experiencing this issue.
If no one can reproduce this, I'll just try to remember to close the issue myself when it stops happening.
The problem is present in every project I've opened vscode on, including the projects of people who aren't experiencing this issue.
I was hoping you could provide a concrete, small example so we could compare.
The issue has ceased :shrug: no idea what changed. As promised, closing issue.
Set up rust and vscode on another machine and it's happening again.
rustc 1.68.0-nightly (88c58e3c2 2022-12-26)
, rust analyzer v0.4.1367 Pre-Release
The only rust related extension I have is rust analyzer and I can't see how any of the others would affect it.
[disabled bookmarks just in case]
Here are some more examples of what the messages are like
Which bound? I need to know.
Which trait bounds?
I've just noticed this setting. It was turned off, it defaults to being turned off. I turned it on, but it didn't change anything.
Why can rust analyzer sometimes output unhelpfully prosaic messages? Where should I start looking in the codebase to begin investigating how this could be happening?
Still no helpful error messages, only the header from the rustc output.
Has to look in the console output which is tricky.
Using the following versions:
beta-aarch64-apple-darwin unchanged - rustc 1.68.0-beta.5 (003b6f24e 2023-02-15)
rust analyzer version: v0.4.1407
@makoConstruct Code diagnostics don't normally look like that, how are you opening them? Can you paste your settings.json
and current list of extensions?
EDIT: never mind, it seems you're clicking the "View Problem" link in the hover popup.
@mrpink76 can you paste a screenshot? You should have a link to show the full error in a new tab.
Code diagnostics don't normally look like that, how are you opening them?
This is how you can open them:
Edit: you already found that.
@makoConstruct see https://github.com/rust-lang/rust-analyzer/pull/13848.
This is how it looks for me, that is with only header of the error message:
This is how it looks for me, that is with only header of the error message:
But before that you should have a hover pop-up, like in @bjorn3's recording above. That one looks a bit differently because it's a native diagnostic, not one from rustc
.
https://github.com/rust-lang/rust-analyzer/pull/13848 looks very interesting, is that available in rust analyzer version: v0.4.1407 ?
Yeah, it's been available for more than a month now (you're running the latest nightly). It even has colors now.
Ahh, switched rust toolchain to nightly and everything started working!
Thanks for the help everyone!
You shouldn't have to change your toolchain, just click this link in the hover (which you seem to avoid):
Switched back to beta and cannot get it to work there
When I hover over the error I get the following popup
When I click View Problem I still only get the header of the error message.
NOTE: When I use the nightly toolchain it mostly works, however it seems to be a bit glitchy and falls back to the header only mode at times. There is an easy workaround though, insert a space before the error and the full error is displayed again.
Just to clarify, using beta, if I click View Problem above I get the following popup:
Can you post your settings?
After investigating my settings.json there was an invalid row in "settings.json", setting a configuration value to "null". After removing the invalid setting it now works the same in both nightly and beta.
Thanks for your help and sorry for not spotting the setting sooner :)
It shouldn't matter, unless you were setting the server path to a rustup-provided rust-analyzer. Which key was that?
I was to quick to dismiss the problem.
By mistake I used toolchain stable instead of beta, so the problem still exists for me using beta, this is my settings.json:
{
"files.autoSave": "afterDelay",
"editor.minimap.enabled": false,
"editor.bracketPairColorization.enabled": true,
"vim.vimrc.enable": true,
"editor.lineNumbers": "relative",
"[dart]": {
"editor.formatOnSave": true,
"editor.formatOnType": true,
"editor.rulers": [
80
],
"editor.selectionHighlight": false,
"editor.suggest.snippetsPreventQuickSuggestions": false,
"editor.suggestSelection": "first",
"editor.tabCompletion": "onlySnippets",
"editor.wordBasedSuggestions": false
},
"git.ignoreWindowsGit27Warning": true,
"[html]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"todo-tree.regex.regexCaseSensitive": false,
"todo-tree.regex.regex": "(//|#|<!--|;|/\\*|^|^[ \\t]*(-|\\d+.))\\s*($TAGS)|(todo!)\\\\(.*\\\\)",
"[markdown]": {
"editor.defaultFormatter": "darkriszty.markdown-table-prettify"
},
"zenMode.centerLayout": false,
"zenMode.hideLineNumbers": false,
"rust-analyzer.checkOnSave.command": "clippy",
"editor.inlineSuggest.enabled": true,
"github.copilot.enable": {
"*": true,
"yaml": false,
"plaintext": false,
"markdown": true,
"javascript": false,
"mermaid": false,
"rust": true
},
"git.confirmSync": false,
"[typescript]": {
"editor.defaultFormatter": "vscode.typescript-language-features"
},
"workbench.preferredHighContrastColorTheme": "Visual Studio Dark",
"workbench.colorCustomizations": {
"editorInlayHint.foreground": "#888a",
"editorInlayHint.background": "#0000"
},
"editor.codeActionsOnSave": {
},
"vim.normalModeKeyBindingsNonRecursive": [
{
"before": ["u"],
"after": [],
"commands": [
{
"command": "undo",
"args": []
}
]
},
{
"before": ["<C-r>"],
"after": [],
"commands": [
{
"command": "redo",
"args": []
}
]
}
],
"github.copilot.advanced": {
},
"vim.useSystemClipboard": true,
"settingsSync.ignoredExtensions": [
"github.copilot"
],
"rust-analyzer.trace.server": "verbose",
"window.zoomLevel": 1,
"rust-analyzer.diagnostics.previewRustcOutput": true
}
You should disable tracing, as it will massively slow down Code, causing a lot of jank. Clippy might also interfere with the diagnostics, so it might be a good idea to disable it for now. And you should focus on the hover view, since the inline one (the one you keep posting) has less information.
So stable and nightly work, but not beta? That's a bit strange. Can you reproduce it outside your project or at least try to focus on a single instance of an error?
fn main() {
println!("Hello, world!");
let x = Lala::new();
}
pub struct Lala { }
impl Lala { fn new() -> Box< LalaTrait> { Box::new(Lala {}) } }
trait LalaTrait { }
impl LalaTrait for Lala { }
After testing the code above it mostly works, even in beta (rustc 1.68.0-beta.5 (003b6f24e 2023-02-15)).
However it breaks at times. One way I got it to break was to insert a space before the trait name like:
fn new() -> Box< LalaTrait>
and doing Cmd+P => "Tasks: Run Build Task" => "rust: cargo check"
This simetimes give me the following hover window:
![image](https://user-images.githubusercontent.com/7203676/219899647-7b563f4e-0af7-47c3-9bc0-b6cd1e1f9d9f.png)
Thanks. I'll test tomorrow, but keep in mind that you shouldn't edit the file after running cargo check, and you should save beforehand, if Code doesn't.
If you edit the file, the diagnostic ranges don't get shifted.
I understand, I ran cargo check after saving the file (have autosave enabled).
For me everything works satisfatory. The glitch where is loses the full error might be "macos" specific and as such probably another bug than this one?
Will give another example of the glitch just in case:
fn main() {
println!("Hello, world!");
let x = Lala::new("xxx");
}
pub struct Lala<'T> {
pub bla: &'T str,
}
impl<'T> Lala<'T> {
fn new(blabla: &'T str) -> &'T dyn LalaTrait<'T> {
Lala { bla: "lala" }
}
}
trait LalaTrait<'T> {}
impl<'T> LalaTrait<'T> for Lala<'T> {}
No code changes, just a new "cargo check/build"
Observe that the underline changes between the two screenshots.
Observe that the underline changes between the two screenshots.
You have two errors there: one from rustc
(the one that says rustc(E0308)
), and one from rust-analyzer
(saying rust-analyzer(type-mismatch)
), which is not enabled by default. Only the first one should have the "details" link.
For me, it looks like:
I did spot a bug, though, I don't get any error from the initial cargo check
:
It does show up when I save the file.
and doing Cmd+P => "Tasks: Run Build Task" => "rust: cargo check"
That's a different -- third -- thing. With "check on save" (called just "check" now), we run cargo check
and read the compiler output as JSON in order to highlight all the error spans, add that "full diagnostic" link etc. When you "Run Build Task", VS Code itself runs cargo check
and shows you the errors like in a terminal. You can do this even after disabling rust-analyzer.
I did spot a bug, though, I don't get any error from the initial
cargo check
:
That is the only issue for me right now, since I have to append a space before the error, which causes autosave to save the file, and the hover:able error to appear :)
Closing, since this issue is a bit of a mess. Consider filing a new one if still needed.
When I do the go to next error thing, it'll show an inline error window with a bit of information about the error, but it's usually not enough information, for instance, it will say "mismatched types", but it will never say which type was expected or which was present. To see that, I have to go scroll around in the command line output, which is frustrating.
I asked around a little bit, and apparently this isn't the normal behavior?
I'm on the pre-release version (v0.4.1078), using vscode 1.67.1
Any advice as to how to figure out what might be happening or fix my installation would be welcome. I've tried clearing my user settings, uninstalling the extension and reinstalling it, disabling extensions that might be interfering, with vscode restarts. Didn't help.