rust-analyzer ignores linkedProjects after version 0.4.2040

[Szybet]

rust-analyzer version: 0.4.2042 (and all above this version)

rustc version: rustc 1.82.0-nightly (92c6c0380 2024-07-21)

editor or extension: vscode, rust-analyzer version: 0.4.2044-standalone

relevant settings: my .vscode/settings.json uses the following options: rust-analyzer.linkedProjects, rust-analyzer.checkOnSave.allTargets, rust-analyzer.cargo.noDefaultFeatures, rust-analyzer.check.command

Basically, every version after 0.4.2040 doesn't work, at all. There are no relevant logs to it, nothing. Rust analyzer still shows warnings at the problems tab, but nothing in the editor itself shows up, no tips, no "go to declaration" buttons are working.

I tried cargo cleaning all directories of all project, purging ~/.rustc and ~/.cargo, nothing. The only difference in the working rust analyzer version is that the ram usage is a bit higher, around a GB

[Szybet]

Someone suggested me that it simply ignores the setting rust-analyzer.linkedProjects because it creates the target directory only in the root directory, which may be the true cause of all of it, so I changed the tittle of the issue

[Veykril]

@davidbarsky

[fw-cc]

I am experiencing similar with this new version, code generated and included in the project is not being indexed in this recent update where it was before, I have reverted to 0.3.2037 and rust-analyzer now functions as expected.

When viewing generated files I am also not being warned that the project is unindexed (unsure whether this behavior is intended).

I have written an example (possibly overkill) of how this manifests with files generated by the rust-protobuf crate.

rust-analyzer version: 0.3.2045

rustc version: rustc 1.79.0 (129f3b996 2024-06-10)

editor or extension: vscode, rust-analyzer version: 0.3.2045

relevant settings: "rust-analyzer.notifications.unindexedProject": true

[davidbarsky]

I'm really sorry about the workflow disruption: I know how annoying it is. I'll work on fixing this regression today.

[davidbarsky]

Right, okay:

1. For @fw-cc's issue, I tested against their minimal reproduction (thank you for providing it! it's not overkill and is incredibly helpful when debugging) and determined that Fix path resolution for child mods of those expanded by include! #17650 is the cause, not feature: teach rust-analyzer to discover linked_projects #17246. I'll work on fixing that, as simply readding the previous match guard breaks the newly added test. fw-cc: you also don't need to enable "rust-analyzer.notifications.unindexedProject": true; that has been superseded by #17246 and will be removed by chore: remove UnindexinedProject notification  #17395 later today.
2. I am unable to reproduce @Szybet's issue by setting rust-analyzer.linkedProjects to different Cargo.toml's in a Cargo workspace—I am seeing IDE functionality continue to work. Can you try providing a minimal reproduction of the behavior you're seeing?

[fw-cc]

Ah apologies for reporting it here and thank you very much for your work on these issues, glad the reproduction helped!

[ObsidianMinor]

@davidbarsky #17660 fixed the regression reported by @fw-cc.

[davidbarsky]

@davidbarsky #17660 fixed the regression reported by @fw-cc.

I missed that PR, my bad! It seems like it landed just after the weekly release was cut.

[alex-haven]

Hello 👋
For @Szybet's issue, we faced the same thing this morning, and fixed it by updating our paths from relative to absolute using the ${workspaceFolder} variable:

"rust-analyzer.linkedProjects": [
-        "my-workspace/Cargo.toml",
+        "${workspaceFolder}/my-workspace/Cargo.toml",
]

EDIT: This is on Windows 10 22H2 (19045.4651)

[matthew-levan]

Hello 👋 For @Szybet's issue, we faced the same thing this morning, and fixed it by updating our paths from relative to absolute using the ${workspaceFolder} variable:

"rust-analyzer.linkedProjects": [
-        "my-workspace/Cargo.toml",
+        "${workspaceFolder}/my-workspace/Cargo.toml",
]

Unfortunately using ${workspaceFolder} to declare absolute paths did not work for me on macos-aarch64 with v0.144.4.

I'm using a .zed/settings.json file in the root of my repository with the following contents:

{
  "lsp": {
    "rust-analyzer": {
      "linkedProjects": [
        "${workspaceFolder}/rust/ares/Cargo.toml",
        "${workspaceFolder}/rust/ares_crypto/Cargo.toml",
        "${workspaceFolder}/rust/ares_guard/Cargo.toml",
        "${workspaceFolder}/rust/ares_macros/Cargo.toml",
        "${workspaceFolder}/rust/ares_pma/Cargo.toml",
        "${workspaceFolder}/rust-assert-no-alloc/Cargo.toml"
      ]
    }
  }
}

[andrewkmin]

Like @matthew-levan, I'm also running macos-aarch64. In my .vscode/settings.json, I tried to use both my standard linked projects path as well as the ${workspaceFolder} fix, but to no avail. Using rust 1.71. Rolling back to 0.4.2037 restores functionality.

Appreciate the work y'all are doing and let me know if there's any more information I could provide.

[JosiahParry]

I am also encountering this issue today.

[matthew-levan]

Update: I used absolute paths (that don't rely on interpolation, i.e. ${workspaceFolder}) and it works now.

[mcmah309]

I also randomly started encountering this issue on all versions I tried today (0.4.2054 (pre-release), 0.4.2037, 0.3.2037, 0.3.2053, 0.3.2029, 0.3.2020) while using vscode.

project.workspace

{
	"settings": {
		"rust-analyzer.linkedProjects": [
			"path/to/project/Cargo.toml",
                       ...
		],
	}
}

I switched using a Cargo.toml for the entire project

[workspace]
members = [
    "path/to/project",
    ...
]

Note: for paths in a workspace Cargo.toml, unlike in a vscode workspace, the ending Cargo.toml should not be added.

On 0.3.2053 everything seemed to work fine with this change.

[momotofu]

This fixed it for me:

"lsp": {
    "rust-analyzer": {
      "initialization_options": {
        "linkedProjects": ["/Users/my-username/path/to/Cargo.toml"]
      }
    }
  }

[Veykril]

@davidbarsky any updates on this? This does look like a rather annoying problem (just ran into this with the default rust-lang/rust config)

[davidbarsky]

@davidbarsky any updates on this? This does look like a rather annoying problem (just ran into this with the default rust-lang/rust config)

I wasn't able to reproduce it (I'm still unable to...), but I realized that I made ManifestOrProjectJson take an AbsPathBuf instead of a Utf8PathBuf, which I think explains this regression. I'll put up a PR fixing this.

[davidbarsky]

Opened #17750.