errors are not displayed

[sehz]

I have a very simple program as below in the VSCode:

fn main() {
    let f = open("test");
    println!("Hello, world!");
}

Rust analyzer doesn't show any errors as expected. Nothing on problems tab.

Other features seems to work.

[Veetaha]

Might I ask you, please, to open VSCode > Help > Toggle Developer Tools, then open Console tab and send its contents here? Also what is the contents of VSCode > Help > About window? And what does your project structure look like (i.e. directories and files, Cargo.toml contents, etc.)

[lnicola]

Note that the error will only be reported if you have rust-analyzer.cargo-watch.enable enabled and save the file.

[sehz]

from console related to rust-analyzer extensions

console.ts:137 [Extension Host] stack trace: Error: canceled by client
    at handleResponse (/Users/<xxx>/.vscode/extensions/matklad.rust-analyzer-0.1.20200217/out/main.js:3467:48)  at processMessageQueue (/Users/<xxx>/.vscode/extensions/matklad.rust-analyzer-0.1.20200217/out/main.js:3294:17) at Immediate.<anonymous> (/Users/<xxx>/.vscode/extensions/matklad.rust-analyzer-0.1.20200217/out/main.js:3278:13)   at processImmediate (internal/timers.js:439:21)

and about:

Version: 1.42.1
Commit: c47d83b293181d9be64f27ff093689e8e7aed054
Date: 2020-02-11T14:44:27.652Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Darwin x64 19.3.0

Cargo watch is enabled. It says it runs on save.

This is a simple cargo project. However, I have many other rust and non other rust projects. Let me see if I can open a this project only.

[lnicola]

I also get those "canceled by client" errors and cargo check works fine for me, so it's probably unrelated.

[Veetaha]

@lnicola Cancelled by client errors and not actually errors, we just don't handle them (i.e. Unhandled promise rejection), though we should... I guess we could return Promise<R | null> here, or handle cancellation errors at callsite: https://github.com/rust-analyzer/rust-analyzer/blob/e91375c763a74ebf3784f2d1df542095eb8a159d/editors/code/src/ctx.ts#L56-L73

[UPD] R | null is not possbile, since null might be a valid return value for a request.

[Veetaha]

It's just the language server protocol requires a response from the server even when the request was canceled by other request

[Veetaha]

@sehz , I suppose you use not the latest version of rust-analyzer, because there should be messages like these ones:

Might I ask you to retry reproducing this having installed the latest extension version from the VSCode marketplace?

[sehz]

I see the extension host message from rust-analyzer:

"rust-analyzer 94fb9ad
"

I was able to see error if I only have this project in a workspace but doesn't work when other projects are loaded. I see Cargo check is running and is reporting some warning but somehow doesn't seem to check this project if other projects are loaded

[lnicola]

I was able to see error if I only have this project in a workspace but doesn't work when other projects are loaded. I see Cargo check is running and is reporting some warning but somehow doesn't seem to check this project if other projects are loaded

Wait, are you using Code workspaces? rust-analyzer doesn't work great on them.

[sehz]

So doesn't work with workspace? that's bummer. I have lots of rust projects.

It's weird. it works in one workspace and but doesn't work in other workspace even thought projects are same.

I also see this in problem:

[Error - 9:40:25 AM] Request textDocument/foldingRange failed.
  Message: Rust file outside current workspace is not supported yet.
  Code: -32600 

[lnicola]

It doesn't work, or not very well, at least -- try searching for issues containing Rust file outside current workspace is not supported yet, there's quite a bunch of them.

Can you use cargo workspaces instead?

[lnicola]

@matklad is the main issue here the fact that ra_vfs doesn't support multiple root directories?

[sehz]

This happens when I add new rust project to workspace.

Cargo workspace is great. However, I have many independent rust projects. Some has cargo workspace, some doesn't. I also have non rust project as well. So need to use VS Code workspace.

[sehz]

Yup. looks like Cargo check doesn't run on some of the projects when you have multiple cargo projects in code workspace. This should be high priority. This limit usefulness of rust analyzer.

[sehz]

also, ra_lsp_server_mac's memory size is 629M. Seems rather large for 37K lines.

Maybe one solution is run cargo check for each project?

[kiljacken]

See #2792. If you're feeling like it's high priority, you're more than welcome to help out :)

[jchitel]

I am seeing this behavior and I am not using workspaces (at least I'm pretty sure I'm not, I may be unclear on exactly what you guys are talking about).

I just have a standard cargo project with several modules. RLS was giving me the correct errors. When I switched to rust-analyzer, everything else works fine, but I am not getting errors.

[Veetaha]

@jchitel to make this clear we are saying that VSCode workspaces (i.e. multiple folders opened in one VSCode instance) are not currently well supported by rust-analyzer. This is how they look like in UI (here vscode and rollup are totally unrelated projects that are not even connected with Rust in this case):

If you don't use this VSCode feature and always have only one folder open in your VSCode instance you should see the errors, otherwise, might I ask you to provide the same info that I described here? Also, a sample reproduction project with vscode settings.json would be very helpful

[sehz]

vs_analyzer_issue.zip

This is a very simple example. error is shown on first project but not second.

Open workspace in the folder

[jchitel]

@Veetaha here is the requested information:

• Console tab:
• About VS Code:

  Version: 1.42.1
  Commit: c47d83b293181d9be64f27ff093689e8e7aed054
  Date: 2020-02-11T14:44:27.652Z
  Electron: 6.1.6
  Chrome: 76.0.3809.146
  Node.js: 12.4.0
  V8: 7.6.303.31-electron.0
  OS: Darwin x64 19.2.0

• Project structure:

• Cargo.toml
• Cargo.lock
• src/
  • ...rust source files...
• .vscode/
  • settings.json
• ...other misc. resources...

• Contents of .vscode/settings.json:

  {
  "rust-analyzer.serverPath": "rust-analyzer",
  "rust-analyzer.cargo-watch.arguments": [
      "--features=\"metal\""
  ],
  "rust-analyzer.cargoFeatures.allFeatures": false,
  "rust-analyzer.cargoFeatures.features": [
      "metal"
  ],
  "rust-analyzer.cargo-watch.allTargets": false,
  "rust-analyzer.trace.server": "verbose"
  }

I originally ran the released version of rust-analyzer and got no displayed errors, so I tried building from source and am seeing the same behavior.

I will try to reproduce this in a fresh project as well.

[Veetaha]

Thank you for the info, I'll try to look into it once I tackle our broken enhanced typing feature (#3013) if anyone else doesn't take this faster ...

[Veetaha]

I did manage to reproduce the bug reported by jchitel. Diagnostics from cargo watch are not reported when you set "cargo-watch.cargoFeatures.features": [ "feature_name" ].

[Veetaha]

@kiljacken , you might want to look into that, just use cargo init to create a hello world project, add the same .vscode/settings.json file as provided higher and the following entry to Cargo.toml:

[features]
metal = []

[Veetaha]

@jchitel removing the quotes around metal here should fix it for youL

{
 "rust-analyzer.cargo-watch.arguments": [
        "--features=metal"
    ],
}

[64kramsystem]

Hello!

I have what I suspect is a very similar issue, so I wanted to double check here before (or instead of) opening a separate issue.

The problem I experience is odd - syntactical errors are detected (and highlighted), for example zzzfn () -> {}, however, semantic ones aren't, like thread::sleep(Duration::from_secs(0)); without use std::thread.

The structure of the workspace is relatively simple:

• a root project with several packages
  • each package has its own Cargo.toml
  • the root has a Cargo.toml with all, except one, packages defined as workspace members
• the extra package has its own Cargo.toml file, with an empty workspace key

The idea behind this setup is to have a separate project that I use for experiments.

I've actually tried several configurations in order to use multiple projects, but none of them ever worked (in terms of rust-analyzer); I thought this was the simplest configuration that would make it work.

There are some minor details, but before considering them, I wanted to know if this is just an unsupported feature.

[bjorn3]

Does cargo check --workspace in the root project work? Using workspaces should would. Wasmtime for example works for me.

[64kramsystem]

Does cargo check --workspace in the root project work? Using workspaces should would. Wasmtime for example works for me.

Hello! Yes, cargo check --workspace works fine (currently, no errors).

To be more specific, rust-analyzer work fine in the context of the (root) workspace and all its packages; the problem happens to the child project.

[bjorn3]

So the problem is with the extra package that has [workspace]? You should be able to use rust-analyzer.linkedProjects then. Something like:

{
    "rust-analyzer.linkedProjects": [
        "./Cargo.toml",
        "./extra_package/Cargo.toml"
    ]
}

[64kramsystem]

So the problem is with the extra package that has [workspace]? You should be able to use rust-analyzer.linkedProjects then. Something like:

{
    "rust-analyzer.linkedProjects": [
        "./Cargo.toml",
        "./extra_package/Cargo.toml"
    ]
}

Thanks for the answer!

I think I used that and surrendered (and removed this setting just today). However, let me double check, and follow up with the result.

[64kramsystem]

So the problem is with the extra package that has [workspace]?

Yes.

You should be able to use rust-analyzer.linkedProjects then. Something like:

{
    "rust-analyzer.linkedProjects": [
        "./Cargo.toml",
        "./extra_package/Cargo.toml"
    ]
}

So!

The problem (as described above) persists, and I confirm that I've previously tried that.

However, while testing again following your advice, I found something that may be indicative. If, in the setting mentioned, I use an invalid filename for the root project's Cargo config file, RA works fine on the child project. See this example:

    "rust-analyzer.linkedProjects": [
      "./Cargo.toml_WRONG",
      "./playground/Cargo.toml"
    ]

As soon as I fix the filename (that is, remove _WRONG), the problem kicks in.

To clarify the problem:

// error not detected
use test::bench::black_boxxxxxxxx;

// error detected
xxxxxxxfn bench(run: bool, name: &str, cycles: u32, cycle_instructions: u32, function: fn(u32, u32)) {
  // blah
}

[bjorn3]

What is the content of the Output > Rust Analyzer Client pane?

[64kramsystem]

What is the content of the Output > Rust Analyzer Client pane?

Result below (paths edited), as soon as I open the workspace (without further actions).

The Rust Analyzer Language Server Trace output is empty. I've tried running with RA_LOG=info, and there is a new panel, Rust Analyzer Language Server, which has a huge amount of data; if you need info from this, I can post it, either filtered or unfiltered.

INFO [8/30/2020, 6:44:04 PM]: Extension version: 0.2.289
INFO [8/30/2020, 6:44:04 PM]: Using configuration {
  lruCapacity: null,
  files: { watcher: 'client', exclude: [] },
  notifications: { cargoTomlNotFound: true },
  cargo: {
    autoreload: true,
    noDefaultFeatures: false,
    allFeatures: false,
    features: [],
    loadOutDirsFromCheck: false,
    target: null
  },
  rustfmt: { extraArgs: [], overrideCommand: null },
  checkOnSave: {
    enable: true,
    extraArgs: [],
    command: 'check',
    overrideCommand: null,
    allTargets: true,
    noDefaultFeatures: null,
    allFeatures: null,
    features: null
  },
  cargoRunner: null,
  runnableEnv: null,
  inlayHints: {
    enable: true,
    typeHints: true,
    chainingHints: true,
    parameterHints: true,
    maxLength: 20
  },
  completion: {
    addCallParenthesis: true,
    addCallArgumentSnippets: true,
    postfix: { enable: true }
  },
  callInfo: { full: true },
  updates: { channel: 'stable', askBeforeDownload: false },
  serverPath: null,
  trace: { server: 'off', extension: false },
  procMacro: { enable: false },
  debug: {
    engine: 'auto',
    sourceFileMap: {
      '/rustc/<id>': '${env:USERPROFILE}/.rustup/toolchains/<toolchain-id>/lib/rustlib/src/rust'
    },
    openDebugPane: false,
    engineSettings: {}
  },
  lens: { enable: true, run: true, debug: true, implementations: true },
  hoverActions: {
    enable: true,
    implementations: true,
    run: true,
    debug: true,
    gotoTypeDef: true
  },
  linkedProjects: [
    '/path/to/libemuls/Cargo.toml',
    '/path/to/libemuls/playground/Cargo.toml'
  ],
  withSysroot: true,
  diagnostics: {
    enable: true,
    enableExperimental: true,
    disabled: [],
    warningsAsInfo: [],
    warningsAsHint: []
  }
}
INFO [8/30/2020, 6:44:04 PM]: PersistentState: {
  lastCheck: undefined,
  releaseId: undefined,
  serverVersion: '0.2.289'
}
INFO [8/30/2020, 6:44:04 PM]: Using server binary at /home/saverio/.config/Code/User/globalStorage/matklad.rust-analyzer/rust-analyzer-linux

[Veetaha]

The structure of the workspace is relatively simple:

• a root project with several packages
  • each package has its own Cargo.toml
  • the root has a Cargo.toml with all, except one, packages defined as workspace members
• the extra package has its own Cargo.toml file, with an empty workspace key

As I see you have two independent cargo workspaces (the extra package forms an independent workspace of one crate on it's own). I believe rust-analyzer doesn't support multiple cargo workspaces (the issue with cargo-check blocks this), but I may be wrong.

As for me, I just open a separate vscode window in ~/junk/rust-sandbox dir if I need to test something quick and dirty. But otherwise it won't harm if you add your extra sandbox crate to the root workspace members.

[64kramsystem]

As for me, I just open a separate vscode window in ~/junk/rust-sandbox dir if I need to test something quick and dirty. But otherwise it won't harm if you add your extra sandbox crate to the root workspace members.

Thanks. I've tried that workaround, and the reason why I was reluctant to implement it, is that, since the project is public, I wanted to keep the sandbox domain separate from the project one. But I guess that until that issue is resolved, I'll probably add it.

[64kramsystem]

Thanks for the help, by the way :slightly_smiling_face:

[lnicola]

The workspace problem seems fixed now:

But this issue is a bit of a mess. If you're still having problems, please file a new one, preferably with a test case attached.

[1336363231]

I was getting the same problem. After I tested it, I found that the cause came from an update commit of my cargo.toml file. In that commit of mine cargo.toml added a new library (vk-mem in my case). I then temporarily commented out that line and saved it, the error message reappeared, then I added the line back again and saved it, and everything was fine. I don't know what the exact reason is, maybe it's something to do with the network? (I need to turn on a proxy to download the dependency crate)