Skip to content

Extension fails to start on latest nightly #18318

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

Closed
bjorn3 opened this issue Oct 17, 2024 · 7 comments · Fixed by #18320
Closed

Extension fails to start on latest nightly #18318

bjorn3 opened this issue Oct 17, 2024 · 7 comments · Fixed by #18320
Assignees
Labels
A-vscode vscode plugin issues Broken Window Bugs / technical debt to be addressed immediately

Comments

@bjorn3
Copy link
Member

bjorn3 commented Oct 17, 2024

The developer tools of vs code show the following:

console.ts:137 [Extension Host] /bin/sh: regel 1: rustc: opdracht niet gevonden
C @ console.ts:137
mainThreadExtensionService.ts:107 Activating extension 'rust-lang.rust-analyzer' failed: Command failed: rustc -V -v
/bin/sh: regel 1: rustc: opdracht niet gevonden

where "opdracht niet gevonden" is Dutch for "command not found".

It works fine with the latest stable version of the extension.

I suspect that #18281 caused this regression. cc @darichey

@bjorn3 bjorn3 added A-vscode vscode plugin issues Broken Window Bugs / technical debt to be addressed immediately labels Oct 17, 2024
@bjorn3
Copy link
Member Author

bjorn3 commented Oct 17, 2024

By the way I'm running vscode inside flatpak, but rust-analyzer automatically gets spawned outside of it by vscode afaik.

@darichey
Copy link
Contributor

darichey commented Oct 17, 2024

I agree #18281 could be related, but it's unclear how: the only commands it should affect are rustup and rust-analyzer --version.

FWIW, I can't repro. I also can't find where rust-analyzer is trying to run that command during activation.
edit: I didn't realize this was in a top level definition, this is it:

execSync("rustc -V -v", {}).toString(),

@davidbarsky
Copy link
Contributor

davidbarsky commented Oct 17, 2024

#18265 seems a little suspicious to me, especially since it's a regex + exec and it calls rustc. We should probably fix and/or revert that PR.

@davidbarsky
Copy link
Contributor

I'll put up a PR with a fix, one moment.

@davidbarsky davidbarsky self-assigned this Oct 17, 2024
@Veykril
Copy link
Member

Veykril commented Oct 17, 2024

Oh my bad, I somehow overlooked that odd call there.

@davidbarsky
Copy link
Contributor

davidbarsky commented Oct 17, 2024

No worries, I'm just doing a slight refactor right now to consolidate where the symbol map is populated.

@davidbarsky
Copy link
Contributor

Opened #18320.

bors added a commit that referenced this issue Oct 17, 2024
…ustc, r=davidbarsky

internal: fix lldb-dap unconditionally calling rustc

Fixes #18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.

I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
bors added a commit that referenced this issue Oct 17, 2024
…ustc, r=davidbarsky

internal: fix lldb-dap unconditionally calling rustc

Fixes #18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.

I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
bors added a commit that referenced this issue Oct 17, 2024
…ustc, r=davidbarsky

internal: fix lldb-dap unconditionally calling rustc

Fixes #18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.

I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
bors added a commit that referenced this issue Oct 18, 2024
…ustc, r=davidbarsky

internal: fix lldb-dap unconditionally calling rustc

Fixes #18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.

I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
@bors bors closed this as completed in c116ff6 Oct 18, 2024
lnicola pushed a commit to lnicola/rust that referenced this issue Oct 22, 2024
…calling-rustc, r=Veykril

internal: fix lldb-dap unconditionally calling rustc

Fixes rust-lang/rust-analyzer#18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.

I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-vscode vscode plugin issues Broken Window Bugs / technical debt to be addressed immediately
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants