Unable to locate source lines when Rust subproject folder is opened in VSCode

[coolbluewater]

Minimal repro: rust_analyzer_workspace_bug.zip

The attached workspace has these files:

rust_analyzer_workspace_bug
├── .vscode
│   └── launch.json
├── Cargo.lock
├── Cargo.toml
└── subproject
    ├── .vscode
    │   └── launch.json
    ├── Cargo.toml
    └── src
        └── main.rs

Quick Repro steps:

1. Unzip the file
2. Run code rust_analyzer_workspace_bug/subproject. (This opens the project at subfolder rather than at the root, in order to reproduce this issue.)
3. Hit F5 to build & run
4. Verify a build error occurs in the Problems pane (due to a deliberate bug inmain.rs.)
5. Click the build error.

Observe: a tab opens with the message "The editor could not be opened because the file was not found."
Expected: the file to open with the cursor on the line containing the bug.

Note: this bug can be mitigated by adding the file subfolder/.cargo/config.toml, with the contents:

[build]
rustflags = ["--remap-path-prefix", "subproject/="]

However, this fixes the above problem, only to introduce an equally serious one: debugger symbols are incorrectly mapped, and breakpoints are not resolved correctly.

I haven't found any way to have both of these work simultaneously:

1. Build errors correctly displaying the correct file and line when clicked.
2. Debugger symbols being correctly resolved during debugging.

So I've needed to comment out the lines in config.toml when debugging, and re-enable them when just compiling.
This is tedious and frustrating and would really appreciate a fix asap.

[davidbarsky]

On which operating system is this? I was able to successfully open and debug rust_analyzer_workspace_bug/subproject/src/main.rs. Debug information showed up for me, but I did have to comment out "this is a deliberate error" to that I could actually build the binary and, well, debug it:

Stepping back, it sounds like "The editor could not be opened because the file was not found." is coming from VS Code, not rust-analyzer and rust-analyzer doesn't really handle debug symbols.

[coolbluewater]

Sorry, should have mentioned, this is on macOS.
Which OS did you test on?
Thanks

[coolbluewater]

Stepping back, it sounds like "The editor could not be opened because the file was not found." is coming from VSCode.

I believe rust-analyzer provides VSCode with the problem info via LSP, so If it's providing the wrong relative path VSCode will show this error, but the cause is rust-analyzer.

[coolbluewater]

@davidbarsky: I re-read the steps you took.

The problem is reproduced WITH the error in the code, so don't comment it out.
The point is to be able to cause the build error and to verify that clicking on the error in the Problems window does not open the file/line.

[davidbarsky]

Which OS did you test on?

This is on MacOS as well. Take a look at the screenshot I've attached: I have a relatively stock setup of rust-analyzer, and I'm not able to reproduce the behavior you are describing.

I believe rust-analyzer provides VSCode with the problem info via LSP, so If it's providing the wrong relative path VSCode will show this error, but the cause is rust-analyzer.

I mean, sometimes that is the case, but it doesn't seem to be applicable now. Is the message "The editor could not be opened because the file was not found" in the diagnostics pane, or...?

The problem is reproduced WITH the error in the code, so don't comment it out.
The point is to be able to cause the build error and to verify that clicking on the error in the Problems window does not open the file/line.

I uncommented "this is a deliberate error" and was able to click on the error in the diagnostics pane. After uncommenting it, i was also able to start VS Code in rust_analyzer_workspace_bug/subproject/src/main.rs by running code subproject in rust_analyzer_workspace_bug.

What version of rust-analyzer are you on? Did you change any settings? Our template has fields for this information, but it appears you've skipped past it, and without this information, I can't help you.

[coolbluewater]

@davidbarsky, could you confirm the main point:
Are you able, with VSCode open at the "subproject" folder, able to get the build error in the Problems pane? And if so, what happens when you click on the build error?

[davidbarsky]

Are you able, with VSCode open at the "subproject" folder, able to get the build error in the Problems pane?

Yes, I can.

And if so, what happens when you click on the build error?

It brings me to the start of line 7, where the error actually is.

[coolbluewater]

And what OS are you on? Also, just double checking that you did not add the cargo/.config.toml mentioned as a workaround in the OP.

I'm on a fairly recent build of rust-analyzer, but the problem has been there for at least a couple of years, (and I suspect forever.) There are no global settings changes to rust-analyzer that I can tell. I've double checked VSCode's settings.json and for a global config.toml.

[coolbluewater]

Also, when you say "diagnostics pane" do you mean the Problems pane? Just making sure we're talking about the same thing.

[coolbluewater]

@davidbarsky, to ensure there isn't a pilot error, here are the minimal repro steps.

Appreciate if you can restart from scratch and:

1. Unzip the file
2. Run `code rust_analyzer_workspace_bug/subproject'
3. Hit F5 to build & run
4. Verify the build error occurs in the Problems pane
5. Click the build error.

For me, this always gives the message "The editor could not be opened because the file was not found."

[davidbarsky]

And what OS are you on? Also, just double checking that you did not add the cargo/.config.toml mentioned as a workaround in the OP.

I did not add this file, correct. I'm using the zip file that your gave me as a reproduction: the only change I made was adding a let hello = "hello!"; to ensure that debug symbols were being read.

I'm on a fairly recent build of rust-analyzer, but the problem has been there for at least a couple of years.

What specific version of the rust-analyzer extension are you using? You can find this clicking, in the menu bar, View > Extensions. This will open the extensions pane in VS Code: please find rust-analyzer and tell and tell me what the version string is next to the name of the extension. Additionally, when you run rustc --version, what is the output?

Also, when you say "diagnostics pane" do you mean the Problems pane? Just making sure we're talking about the same thing.

Yes, that is what I'm referring to.

Appreciate if you can restart from scratch and:

Okay, I'm able to reproduce this and I understand what's going on here. For the future, please start issues with the steps you provided to save some time—what you provided initially was sufficient for us to reasonably reproduce your issue (we also have a template for bug reports: please use it; it makes our jobs far easier). Quick question: why do you want to open rust-analyzer in rust_analyzer_workspace_bug/subproject and not rust_analyzer_workspace_bug? For Cargo workspaces, rust-analyzer generally expects you to open it at the root of the Cargo workspace.

[coolbluewater]

@davidbarsky

Okay, I'm able to reproduce this and I understand what's going on here.

Good to hear.

Quick question: why do you want to open rust-analyzer in rust_analyzer_workspace_bug/subproject and not rust_analyzer_workspace_bug?

The use case is a monorepo with a root workspace and team project folders under that, each containing multiple crates. The single workspace unifies dependency management. The team projects also have dependencies between them, but that does not necessitate a deeper hierarchy. Each team works within its own project folder, so opens VSCode to that folder. This works very well except for the current issue.

For Cargo workspaces, rust-analyzer generally expects you to open it at the root of the Cargo workspace.

That imposes a constraint that neither Rust or VSCode inherently have.

[Veykril]

I think I caused this, #17605 should fix that (we were no longer using the source map)

[coolbluewater]

@Veykril, the issue I'm reporting has been around for a long time.

Appreciate if you could test your patch against the quick repro steps, repeated here:

1. Unzip the file attached in the OP above.
2. Run `code rust_analyzer_workspace_bug/subproject'
3. Hit F5 to build & run
4. Verify a build error occurs in the Problems pane (caused by a deliberate error in the Rust code.)
5. Click the build error.

If the patch fixes the issue, step 5 should open the rust file at the line corresponding to the problem.

Currently, step 5 triggers the message "The editor could not be opened because the file was not found."

[davidbarsky]

@coolbluewater

The use case is a monorepo with a root workspace and team project folders under that, each containing multiple crates. The single workspace unifies dependency management. The team projects also have dependencies between them, but that does not necessitate a deeper hierarchy. Each team works within its own project folder, so opens VSCode to that folder. This works very well except for the current issue.

I would recommend opening at the root of the Cargo workspace for reasons I'll explain momentarily.

That imposes a constraint that neither Rust or VSCode inherently have.

I understand that: I'm offering you a workaround. Anyways, the issue is not in rust-analyzer; it is in the interaction between --remap-path-prefix, split-debuginfo on macOS, and Cargo:

• --remap-path-prefix is used by the rust-analyzer server (which the build-and-run action prompted by F5 does not invoke!) to remap diagnostics emitted by rustc map to their appropriate location. However, --remap-path-prefix remaps all paths, including debug information, resulting in you seeing breakpoints not working.
• split-debuginfo, which is the the default on macOS, needs the paths in order to accurately load the DWARF debug information, but since the paths are no longer relative to the target directory, the breakpoints are no longer hit.
• Cargo would really like to have a single target directory, so while rust-analyzer could fix this in the extension, it's probably not the right fix for most people because that'd cause more cache misses/invalidations. We get frequent complaints about that.

The right fix, I think, would be a weaker form of --remap-path-prefix that only remaps the diagnostics, and nothing else. I've wanted something similar for buck2.

In any case, I'm closing this issue, as there's little we can reasonably do at the moment.

[coolbluewater]

@davidbarsky

Thanks for the info. BTW did this line get truncated:

split-debuginfo, which is the the default on macOS, needs to

[davidbarsky]

@davidbarsky

Thanks for the info. BTW did this line get truncated:

split-debuginfo, which is the the default on macOS, needs to

Yes, that was an accident. I just fixed that.

[coolbluewater]

@davidbarsky

Cargo would really like to have a single target directory, so while rust-analyzer could fix this in the extension, it's probably not the right fix for most people because that'd cause more cache misses/invalidations. We get frequent complaints about that.

Guess I don't understand this, appreciate if you could break down:
a) How might rust-analyzer fix this in the extension?
b) How would that impact cargo and the target directory?

[coolbluewater]

@davidbarsky, the current behavior is completely broken. I don't see how fixing rust analyzer to do the right thing could in any way be worse than the current situation. You're bringing up performance as a reason to not fix a broken behavior bug? Make it make sense, please. This bug is a serious one for those impacted by it and will not just go away by itself.

[Veykril]

Okay, having re-read this, I believe the issue is rust-lang/cargo#9887. Cargo reports file paths relative to the cargo workspace, not the current working directory which means the problem matcher regex will incorrectly receive subproject/src/main.rs:6:10 (which is relative to the top level cargo workspace) which ends up pointing to subproject/src/main.rs which obviously does not exist from the vscode workspace (as we are in subproject).

That is rust-analyzer can't really do anything here as this is a bug with cargo handing us paths that do not correspond to the current working directory which is the only thing we can work with at the extension level.

[coolbluewater]

@Veykril, thanks for the reference, rust-lang/cargo#9887 shows that others have also indicated their frustration at this issue.

Please see above where @davidbarsky indicates that this could be fixed in rust-analyzer, wonder what he has in mind?

Be great to have a proposal no matter which component it is in, we can make sure it gets to the right team.

[coolbluewater]

A Critique of Pure NotMyProblemItis

A recurring theme in this issue is: "there's nothing rust-analyzer can do, this is a vscode (or cargo) issue."
This is, sadly, plain wrong. There is much you can do, and ought to do. Net: your component has a bug - it is emitting incorrect paths. Nothing forces you to use paths computed by external crates. If you do, you need to take responsibility for bugs in those calculations and ensure that those bugs are fixed.

If VSCode (or cargo) was broken in a way that some fundamental rust-analyzer functionality was broken, for sure you would be on the case, investigating, filing bugs against vscode/cargo and pushing until a fix was made that restored rust-analyzer's own functionality.

This issue falls into exactly the same category, except that you folks seem disinclined for whatever reason to do anything about it. Case in point, @davidbarsky lets slip that "rust-analyzer could fix this in the extension", but stops responding when asked how.

Anyhow, this issue is a cross-boundary issue, and you own one half of the cross-component chain, and it's your components' behavior that is impacted. So it is really up to you to pursue the issue through to completion.

Instead, you throw your hands up and leave it up to a normal user, me, who has made considerable efforts to get this fix underway by providing clear steps to reproduce the issue, to figure out the innards of what might be going wrong in order to be the intermediary between the two teams? What an apathetic situation.

As they say, where there's a will there's a way. I know this post may lead to petulant refusal, but TBH it looks like we're already there.

Closing this issue summarily in this half-investigated state is totally inappropriate.

I hope that some of the leads will take notice.

[davidbarsky]

While I understand that you are frustrated, your tone is coming off as needlessly hostile when we are trying to help you. Threatening professional repercussions in the form of "I hope that some of the leads will take notice" falls into the category of hostility. I will involve the moderation team if you continue to behave in this way. For the future: we, or any other maintainer, are under no obligation to respond or help you, for any reason whatsoever. The software here is provided as is, without warranty of any kind.

If VSCode (or cargo) was broken in a way that some fundamental rust-analyzer functionality was broken, for sure you would be on the case, investigating, filing bugs against vscode/cargo and pushing until a fix was made that restored rust-analyzer's own functionality.

I'm only responding to this in a show of good faith: I was speaking to several members of the Cargo/compiler teams privately about a weaker, diagnostics-only form of --remap-path-prefix that only applies to diagnostics because I want similar functionality in other contexts.

This issue falls into exactly the same category, except that you folks seem disinclined for whatever reason to do anything about it. Case in point, @davidbarsky lets slip that "rust-analyzer could fix this in the extension", but stops responding when asked how.

We had other priorities. I tried out a naive solution with --remap-path-prefix in the client, which did not work. In the short term, one avenue would be to make rust-analyzer.diagnostics.remapPrefix be respected by the VS Code extension. I do not have time to implement this, but if you're willing to open a PR with these change, I will review it.

Additionally, please refrain from @'ing me. I check my GitHub notifications multiple times per day.

[coolbluewater]

While I understand that you are frustrated, your tone is coming off as needlessly hostile when we are trying to help you.

You closed the issue and stopped responding to questions which is what motivated my critique. Is that what you call "trying to help"? Sorry, you words are not not congruent with your actions.

Threatening professional repercussions in the form of "I hope that some of the leads will take notice" falls into the category of hostility. I will involve the moderation team if you continue to behave in this way.

I do hope the leads take notice. I am making the case for this to be reopened and worked on. That is seen by you as a threat? Ridiculous. You're the one threatening senselessly. To be clear, I'm not here to have my time wasted - if you can help then do so. I am desperate to have this issue fixed. Period. If you think this is personal I have nothing to say to you.

I'm only responding to this in a show of good faith: I was speaking to several members of the Cargo/compiler teams privately about a weaker, diagnostics-only form of --remap-path-prefix that only applies to diagnostics because I want similar functionality in other contexts.

Github users are not mind readers and can only respond to observed actions. It would have been better to mention that investigations were ongoing and to leave the issue open. By the way, it is still closed. In any event, this is more appealing a discussion to have.

One idea - perhaps just add a simple API to let rust-analyzer know which folders the the a) build and b) diagnostics are relative to? I understand it's a security issue print the absolute paths of these two folders (build and diagnostics roots) to the console or to a build log, but don't think it's a security issue to pass the absolute paths via an API to another component.

[coolbluewater]

@davidbarsky are you going to reopen this issue? Closing an issue cuts it off from anybody else taking an interest in it and dooms it to non-resolution.

You mentioned that you "check my GitHub notifications multiple times per day" so hoping for a speedy response.

[coolbluewater]

@davidbarsky, kindly refrain from this issue going forward, done with this weirdness WADR.

@Veykril, I've looked at rust-lang/cargo#9887, and it may be relevant here. Now this present issue is that we can specifically either get build paths to work OR diagnostics paths to work, but not both at the same time, conditioned on --remap-path-prefix. Further, rust-analyzer presumably knows (or can sniff) the environment settings and flags. Given this, is it possible to fix the issue within rust-analyzer without relying on fix in cargo?