Closed EndilWayfare closed 1 year ago
EndilWayfare
commented
3 years ago Looks like it goes a layer deeper: It's not just gtk types that aren't checked, it looks like no types are checked. Further, it looks like no analysis is being done on the actual Rust AST, just syntax parsing.
This listing is in lib.rs, not main.rs, and it doesn't even import any items, gtk-related or otherwise:
Veykril
commented
3 years ago Rust-Analyzer itself doesnt emit type mismatches yet, we only show the rustc type mismatch diagnostics which you aren't receiving due to the cargo check failing I believe.
I assume you are setting some env vars for the project to compile, try mirroring those to the "rust-analyzer.server.extraEnv" setting. That should get rust-analyzers cargo check working again, assuming its missing env variables.
EndilWayfare
commented
3 years ago That's what I thought at first, but it's still happening after I got rust-analyzer's cargo check to succeed.
I went ahead and modified my global env vars, loath though I was, and it stopped complaining about cargo check. "rust-analyzer.server.extraEnv" sounds lovely in the general case, though; I'll have to give that a try.
EndilWayfare
commented
3 years ago Output > Rust Analyzer Client seems normal:
INFO [7/14/2021, 5:50:53 PM]: Extension version: 0.2.670
INFO [7/14/2021, 5:50:53 PM]: Using configuration {
cargoRunner: null,
runnableEnv: null,
inlayHints: {
enable: true,
smallerHints: true,
chainingHints: true,
maxLength: 25,
parameterHints: true,
typeHints: true
},
updates: { channel: 'stable', askBeforeDownload: false },
server: { path: null, extraEnv: null },
trace: { server: 'off', extension: false },
debug: {
engine: 'auto',
sourceFileMap: {
'/rustc/<id>': '${env:USERPROFILE}/.rustup/toolchains/<toolchain-id>/lib/rustlib/src/rust'
},
openDebugPane: true,
engineSettings: {}
},
assist: {
importGranularity: 'crate',
importEnforceGranularity: false,
importPrefix: 'plain',
importGroup: true,
allowMergingIntoGlobImports: true,
importMergeBehaviour: 'last'
},
callInfo: { full: true },
cargo: {
autoreload: true,
allFeatures: false,
unsetTest: [ 'core' ],
features: [],
runBuildScripts: true,
useRustcWrapperForBuildScripts: true,
noDefaultFeatures: false,
target: null,
noSysroot: false,
loadOutDirsFromCheck: true
},
checkOnSave: {
enable: true,
allFeatures: null,
allTargets: true,
command: 'clippy',
noDefaultFeatures: null,
target: null,
extraArgs: [],
features: null,
overrideCommand: null
},
completion: {
addCallArgumentSnippets: true,
addCallParenthesis: true,
postfix: { enable: true },
autoimport: { enable: true },
autoself: { enable: true }
},
diagnostics: {
enable: true,
enableExperimental: true,
disabled: [],
remapPrefix: {},
warningsAsHint: [],
warningsAsInfo: []
},
experimental: { procAttrMacros: false },
files: { watcher: 'client', excludeDirs: [] },
highlighting: { strings: true },
hover: { documentation: true, linksInHover: true },
hoverActions: {
debug: true,
enable: true,
gotoTypeDef: true,
implementations: true,
references: false,
run: true
},
joinLines: {
joinElseIf: true,
removeTrailingComma: true,
unwrapTrivialBlock: true
},
lens: {
debug: true,
enable: true,
implementations: true,
run: true,
methodReferences: false,
references: false
},
linkedProjects: [],
lruCapacity: null,
notifications: { cargoTomlNotFound: true },
procMacro: { enable: true, server: null },
runnables: { overrideCargo: null, cargoExtraArgs: [] },
rustcSource: null,
rustfmt: {
extraArgs: [],
overrideCommand: null,
enableRangeFormatting: false
},
workspace: { symbol: { search: { scope: 'workspace', kind: 'only_types' } } }
}
INFO [7/14/2021, 5:50:53 PM]: Using server binary at c:\Users\{path anonymized}\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-x86_64-pc-windows-msvc.exeServer errors and the like will be output in Output > Rust Analyzer, the client logs usually don't show server errors. So anything of interest for this problem here should be in those logs instead.
Are you doing anything special aside from setting env vars when building the project?
And just to make sure, do you have check on save enabled(thought this should be on by default I believe)?
EndilWayfare
commented
3 years ago Nope, just env vars.
Yep, check on save is enabled.
EndilWayfare
commented
3 years ago Output > Rust Analyzer Language Server Trace with "rust-analyzer.trace.server": "verbose":
Mostly noise, but an interesting bit in the middle:
// Still complaining about my intentional syntax error
[Trace - 5:55:31 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {
"uri": "file:///c:/Users/{path anonymized}/crossi/crossi/src/lib.rs",
"diagnostics": [
{
"range": {
"start": {
"line": 5,
"character": 38
},
"end": {
"line": 5,
"character": 39
}
},
"severity": 1,
"source": "rustc",
"message": "expected one of `!`, `(`, `+`, `,`, `::`, `:`, `<`, `=`, or `>`, found `[`\nexpected one of 9 possible tokens"
},
// *gasp* Ooh, look at this! It *is* finding out that `lol` isn't a real variable
// it's just not reporting it for some reason
{
"range": {
"start": {
"line": 2,
"character": 42
},
"end": {
"line": 2,
"character": 45
}
},
"severity": 1,
"code": "E0425",
"codeDescription": {
"href": "https://doc.rust-lang.org/error-index.html#E0425"
},
"source": "rustc",
"message": "cannot find value `lol` in this scope\nnot found in this scope"
}
]
}Following up on the "error detected but not reported" discovery, I reintroduced my type misuse to main.rs
window.action_removed(42)No additional 'textDocument/publishDiagnostics' notifications.
But some interesting auto-complete stuff:
[Trace - 7:24:13 PM] Received response 'textDocument/completion - (103)' in 94ms.
Result: {
"isIncomplete": true,
"items": [
{
"label": "unsafe",
"kind": 14,
"deprecated": false,
"sortText": "ffffffff",
"filterText": "unsafe",
"insertTextFormat": 2,
"textEdit": {
"newText": "unsafe {\r\n $0\r\n}",
"insert": {
"start": {
"line": 6,
"character": 26
},
"end": {
"line": 6,
"character": 30
}
},
"replace": {
"start": {
"line": 6,
"character": 26
},
"end": {
"line": 6,
"character": 30
}
}
},
"additionalTextEdits": []
},
...
// The entire Rust lexicon
...
{
"label": "ObjectType",
"kind": 8,
"documentation": {
"kind": "markdown",
"value": "Implemented by types representing `glib::Object` and subclasses of it."
},
"deprecated": false,
"sortText": "ffffffff",
"filterText": "ObjectType",
"textEdit": {
"newText": "ObjectType",
"insert": {
"start": {
"line": 6,
"character": 26
},
"end": {
"line": 6,
"character": 30
}
},
"replace": {
"start": {
"line": 6,
"character": 26
},
"end": {
"line": 6,
"character": 30
}
}
},
"additionalTextEdits": []
},
...
// Too many other entries to count
...
],
}Further cementing the idea that rust-analyzer is able to find out a lot about gtk and friends, but not enough to emit errors...
EndilWayfare
commented
3 years ago Checking "Output > Rust Analyzer Language Server"
RA_LOG=info vomits forth an incalculable volume of logs, dominated by [INFO salsa::derived::slot]
RA_LOG=warn seems benign:
[WARN rust_analyzer::main_loop] overly long loop turn: 277.8365ms
[WARN rust_analyzer::main_loop] overly long loop turn: 106.8794msThose are only emitted on startup and not when Rust Analyzer: Reload workspaceing, so I'm guessing it's down to resource/scheduling contention among initializing extensions.
Limiting RA_LOG=rust_analyzer=info is slightly more tractable:
In there somewhere:
[INFO rust_analyzer::main_loop] handle_event(AddDiagnostic { workspace_root: "c:\\Users\\{path anonymized}\\crossi", diagnostic_code: Some("clippy::eq_op") })
[INFO rust_analyzer::main_loop] handle_event(AddDiagnostic { workspace_root: "c:\\Users\\{path anonymized}\\crossi", diagnostic_code: None })Yep, ok, there's clippy being pedantic.
EndilWayfare
commented
3 years ago Ok, um, this is weird. cargo check diagnostics suddenly start working if I launch VS Code from my Git Bash by entering code at the prompt.
No idea why that would be. Something in the bash environment must be propagating to the VS Code process that propagates to the rust-analyzer process that propagates to the cargo process that makes cargo check work. Maybe it's that mingw translates the PATH env var from C:\ form to /c/, and something in my messed up Windows environment makes rust-analyzer prefer that?
Well wait, that's not right. Cargo check can't be failing when I launch VS Code the normal way... because rust-analyzer isn't complaining about it in it's status indicator anymore. Unless... it runs cargo check in a different way to get diagnostics than it does to... do whatever health-check makes the status go yellow?
Maybe it's some other env var that's being passed through...
EndilWayfare
commented
3 years ago Erm, for completeness, here's RA_LOG=rust_analyzer=info for the works-because-I-launched-it-from-bash configuration:
In there somewhere:
[INFO rust_analyzer::main_loop] handle_event(AddDiagnostic { workspace_root: "c:\\Users\\{path anonymized}\\crossi", diagnostic_code: Some("E0308") })
[INFO rust_analyzer::main_loop] handle_event(AddDiagnostic { workspace_root: "c:\\Users\\{path anonymized}\\crossi", diagnostic_code: Some("E0308") })
[INFO rust_analyzer::main_loop] handle_event(AddDiagnostic { workspace_root: "c:\\Users\\{path anonymized}\\crossi", diagnostic_code: None })
[INFO rust_analyzer::main_loop] handle_event(AddDiagnostic { workspace_root: "c:\\Users\\{path anonymized}\\crossi", diagnostic_code: None })
[INFO rust_analyzer::main_loop] handle_event(AddDiagnostic { workspace_root: "c:\\Users\\{path anonymized}\\crossi", diagnostic_code: None })Hmm, let's see... "E0308"... Ah, yep, "Expected type did not match the received type." That's the one.
EndilWayfare
commented
3 years ago Ok, it gets weirder.
I think it was just coincidence that the VS Code window launched from bash worked. It's just that, for whatever reason, it works more often. Sometimes, a Code window launched that way doesn't work, I reload the window, and then it works.
A window launched the regular way can sometimes work if I reload the window enough times. I have no idea why. (Honestly, I have no idea why I kept stubbornly reloading the window over and over, other than spite and desperation... which paid off? I'm not sure I like the lesson VS Code is trying to reinforce... 😆)
Soo... I closed all my other open VS Code workspaces, exited VS Code, and started it regularly. cargo check diagnostics worked immediately. Closing and relaunching repeatedly produced the same result every time, ruling out (somewhat) the weird probabilistic stuff that seemed to be happening.
TL;DR... maybe it was down to having too many open workspaces? Seems like a "Duh" solution, but reduced in duh-factor by the fact that the interface didn't suggest that anything was wrong. Maybe there's something in all those logs that does, but I don't know what I'm looking for. I don't know how common this is/might be; I've had this many Rust workspaces active simultaneously for a while (sometimes significantly more) and never had this problem crop up. Maybe it's because gtk and friends are very heavily FFI-oriented? I haven't used that many crates of that kind on a project before, but plenty projects with more (and larger) pure-Rust dependencies.
Anyhow, I hope this "diagnostics may stop working with no indication if VS Code has too much going on" helps somebody else and/or indicates something deep in the bowels of rust-analyzer's machinery. Maybe it's a transient thing that'll go away automatically when reliance on cargo check is reduced?
lf-
commented
3 years ago Heh, I've definitely had issues with spam from salsa. I ended up with this RA_LOG: "RA_LOG": "info,salsa::derived::slot=warn,flycheck=trace,rust_analyzer::main_loop=warn,ide_db::apply_change=warn,project_model=debug,proc_macro_api=debug,hir_expand::db=error,ide_assists=debug,ide=debug" for debugging the usual stuff that goes wrong.
EndilWayfare
commented
3 years ago @lf-, wow, that's super helpful! I'll have to refer back to that incantation in the event of future debugging.
EndilWayfare
commented
3 years ago Update: cargo check diagnostics are still very spotty. Sometimes they show up, sometimes they don't. Sometimes they don't show up, then start showing up again after I've run cargo check manually.
Veykril
commented
1 year ago is this still a problem for you?
rust-analyzer, 0.2.670rustc1.53.0 withstable-x86_64-pc-windows-msvctoolchainDisclaimer: I acknowledge that I have something of a weird setup. GTK+ development on windows is all kinds of wonky.
I finally got gtk-rs compiling on Windows 10 (
gtk = "0.14", GTK+3 3.24.28 viagvsbuild; plainmsys2method with Ruststable-gnutoolchain didn't work well). Unfortunately, it's still not playing perfectly withrust-analyzer.Type hint annotations for
It knows that, e.g., 
But it's not yelling at me when I pass an argument of incorrect type:
The second screenshot shows that it is still emitting some errors, but things like
gtktypes are showing up, and auto-complete seems to be working, which indicates thatrust-analyzerhas some understanding ofgtk's structure:window.action_removedmethod takes an argument namedaction_nameof type&str:Syntax Errorthat are global to rust and not dependent on analysis of a crate.Checking the status bar, I saw that the
rust-analyzerindicator was in yellow with a warning-exclamation-point-triangle next to it. On hover, it had this to say:Okay, that makes some sense, luckily. This is the same problem I was having with
cargobefore adding the "bin" directory of my compiled gtk toPATH. I used theterminal.integrated.env.windowssetting in my ".code-workspace" file to augment myPATHsocargobehaved correctly, but it seems that doesn't apply torust-analyzerextension. No similar setting seems to affect it either. Okay, fine: I'll pollute my whole user-levelPATH, I guess, which shouldn't cause any immediate conflicts elsewhere and hope that I remember this if I encounter any future binary resolution weirdness.After updating
PATHand reloading VS Code,rust-analyzerloads completely without the warning, but the same exact problem persists: it knows what the types are but doesn't error on misuse.I'll admit I've become somewhat dependent on
rust-analyzer's analysis for development momentum, especially when first using unfamiliar crates (thanks for the awesome tool, BTW!). This is even more the case now that cargo development builds post-1.52 are much slower (withgtkespecially, even after doing everything possible to force-enable incremental compilation on dev/test builds; I'llcargo cleanmanually if I run into an ICE).