Skip to content
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

bug: VSCode settings break things when opening a subfolder #39

Open
3 tasks done
KrisCarr opened this issue Aug 17, 2023 · 0 comments
Open
3 tasks done

bug: VSCode settings break things when opening a subfolder #39

KrisCarr opened this issue Aug 17, 2023 · 0 comments
Labels
bug Something isn't working

Comments

@KrisCarr
Copy link

Did you check docs and existing issues?

  • I have read all the neoconf.nvim docs
  • I have searched the existing issues of neoconf.nvim
  • I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.9.1

Operating system/version

Linux or MacOS

Describe the bug

Relative paths in values within .vscode/settings.json files don't work if being pulled from a parent directory outside the scope/folder currently being opened in nvim.

My particular issue context

I have a nested folder structure containing multiple "projects" with the top-level containing a .vscode/settings.json file.

There is a setting for rust analyzer that goes into vscode's settings.json called LinkedProjects where you put an array of relative paths for vscode to pick up your projects properly.

This essentially keeps vscode working as expected when you have one or more rust projects not at the root folder.

How it's breaking

When opening one of these in nvim so that a single rust project is essentially the root folder, it breaks rust analyzer (oddly just all proc macros) with a pretty much un-Googleable error:

proc macro main not expanded: proc macro crate is missing dylib

This is due to it going up beyond the root folder being opened, finding a .vscode/settings.json file up in a parent folder somewhere and applying those settings relative to the folder you have opened in nvim NOT relative to the .vscode folder it found the settings in.

Workaround

My current workaround after realising what was breaking it was to just have a .neoconf.json file inside each subfolder setting import -> vscode to false:

{
    "import": {
        "vscode": false
    }
}

Not great if you actually need other settings from vscode's settings but at the moment I don't.

Steps To Reproduce

I imagine there is a much simpler way to reproduce the underlying issue but in my specific case:

  • Install rust with rustup.

  • Install nvim (I used LazyVim this time but all others I tried such as Astro etc all reproduced it).

  • Add rust-analyzer with Mason.

  • Quit nvim.

  • Create a new folder to act as the root folder and within it create the following .vscode/settings.json file:

{
    "rust-analyzer.linkedProjects": [
        "./stuff/Cargo.toml"
    ]
}
  • Create a new sub project with cargo new stuff
  • Add something to the dependencies that uses proc macros to the Cargo.toml file, ie:
[dependencies]
tokio = { version = "1.32.0", features = ["full"] 
  • Then use it in src/main.rs:
#[tokio::main]
async fn main() {
    println!("Hello, world!");
}
  • Now the hierarchy should look like:
    /.vscode/settings.json
    /stuff/Cargo.toml
    /stuff/src/main.rs
    other files created automatically by cargo new omitted.

  • cd into stuff and run:

nvim .
  • Go into main.rs, wait for rust-analyzer to index and be greeted with an error on the #[tokio::main] line.

Expected Behavior

Ideally either:

  • do not load .vscode/settings.json files from a parent outside the current folder scope.
  • if loading values that are relative paths, change them to still be correct (maybe prepend /../ as needed).

Repro

I used the current out-the-box LazyVim
@KrisCarr KrisCarr added the bug Something isn't working label Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant