Rls: Cannot open file on Windows

[hban]

I'm testing VS Code extension on Windows - I cannot get anything to work at the moment, but the following keeps getting printed on the stderr:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value:
Io(Some("/d%3A/Documents/rustls/src/server.rs"), Some("Could not open file: /d%3A/Documents/rustls/src/server.rs"))',
../src/libcore\result.rs

Looks like the path is URL encoded, maybe that's causing issues?

[nrc]

Yeah, the file name comes from a file URL and we hack the translation rather than do it properly. The fix I suppose is to properly translate that URL into a Path. This is currently done by the file_name function in lsp_data.rs, it is buried in a macro. I'm afraid I don't have a Windows machine to test this on, so I can't help fix this.

[nrc]

To be clear though, we'd be very happy to have a fix! And happy to help with advice, etc.

[Arnavion]

The current implementation is wrong for Linux as well :) , since you just snip off the file:// from the front of the URL without properly URL-decoding it. If you create a Linux directory with : or some other character that would be URL-encoded, you would have the same issue.

[Arnavion]

The simple solution of Url::to_file_path unfortunately fails because of https://github.com/servo/rust-url/issues/230

[Arnavion]

As a starting point, I've replaced String/str with PathBuf/Path as appropriate. You can see the WIP at

• https://github.com/nrc/rls-analysis/compare/master...Arnavion:pathbuf
• https://github.com/nrc/rls-vfs/compare/master...Arnavion:pathbuf
• https://github.com/jonathandturner/rustls/compare/master...Arnavion:pathbuf Note that to use this you'll need to add [replace] "url:1.2.1" = { git = "https://github.com/Arnavion/rust-url#fix-230" } Not needed any more since 1.2.2 with the fix has been released.

Currently there are no more "Could not open file" errors, but rls-analysis returns no results for either hover or gotodef. If I force rls to use racer (by failling back to racer if rls-analysis returns no results), then gotodef works.

Edit: So the reason rls-analysis doesn't find anything is because actions_ls::build() always fails with BuildResult::Err, so it doesn't call AnalysisHost::reload, so the internal analysis is always None.

Edit 2: The folder I was testing on was a workspace, so cargo build failed. Once I opened a regular crate directory, build succeeded, but rls-analysis still returns 0 results for hover and gotodef because raw analysis doesn't find any crates. That in turn is because it looks for and doesn't find the save-analysis file. The README makes it seem that this file is only needed for working with the standard library, but is this needed just for using gotodef within a local function?

[Arnavion]

@jonathandturner @nrc Is it expected that gotodef / hover will not work in a local file because the save-analysis file is not present?

Also, since rust-url 1.2.2 has been released with the fix for to_file_path, do you think it makes sense to merge the three branches I have above? I haven't tested them on Linux (my Linux machine isn't nearly powerful enough to compile rustls :( ) so if you or someone else could help test that there are no regressions, that'll help. At the very least it fixes the file not found errors on Windows.

[jntrnr]

@Arnavion - gotodef/hover should work for local files, once all the issues with Windows are fixed. Where it won't work will be std lib symbols if you don't have the save-analysis for them.

I'm currently working on getting a Windows image set up so I can start trying out the RLS in windows. Happy to hear that some of the work we need to do are already starting to show up in the deps.

[Arnavion]

gotodef/hover should work for local files

Hmm, I'm not seeing how though. Since raw analysis doesn't find the file, it never populates the Analysis's crate map with anything, so goto_def and hover have no crates to iterate over and look inside.

[jntrnr]

@Arnavion - ahh, so you think there's a problem in the rustc side as well?

[Arnavion]

1. I open the folder C:\foo\bar in VSCode.
2. AnalysisHost::reload() is called in response to the diagnosticBegin message.
3. Since at this point self.analysis is still a mutex around None, needs_hard_reload is set to true, which calls self.hard_reload
4. hard_reload calls lowering::lower with raw_analysis initialized by raw::Analysis::read with C:\foo\bar as the path_prefix.
5. raw::Analysis::read calls read_internal which builds a path list C:\foo\bar\target\rls\$target\save-analysis, C:\foo\bar\target\rls\$target\deps\save-analysis, C:\foo\bar\libs\save-analysis. None of these exist; in particular C:\foo\bar\target\rls itself doesn't exist.
6. As a result, DirectoryListing::from_path returns an Err for the very first path, which means read_incremental returns an empty vector, i.e. no crates.
7. Thus lowering::lower has no crates to iterate over, so never calls the callback that would've inserted crates into Analysis::per_crate, thus that map remains empty.

Subsequently, when AnalysisHost::goto_def is called from ActionHandler::goto_def:

1. It calls Analysis::def_id_for_span
2. Analysis::def_id_for_span tries to iterate over the crates it has with self.for_each_crate, but this map is empty, so it returns None which self.read converts into Err(())
3. ActionHandler::goto_def converts this to an empty vector of results. Thus the gotodef has no results.

[nrc]

The above basically sounds right and expected behaviour. The only ut that sounds wrong is that the save-analysis data is not present. Does the build actually run? Does it dump data in the wrong place? Or not at all?

[Arnavion]

Okay, so the build should've produced the save-analysis file? I'll check why it didn't.

[jntrnr]

@Arnavion - I noticed that there were some unix paths in the code (https://github.com/jonathandturner/rustls/issues/63) which probably aren't helping

[Arnavion]

Aha, I missed that one.

btw, in case you didn't notice, I did a bunch of the work already in the branches listed in https://github.com/jonathandturner/rustls/issues/54#issuecomment-254995134

[Arnavion]

I can see that save-analysis runs for the crate with this commandline

rustc src\main.rs --crate-name test --crate-type bin -g -C metadata=56dd10082453f7be --out-dir c:\Stuff\Sources\rust\target\rls\debug --emit=dep-info,link -L dependency=c:\Stuff\Sources\rust\target\rls\debug\deps --extern url=c:\Stuff\Sources\rust\target\rls\debug\deps\liburl-9a52f6193ca73c96.rlib -Zunstable-options -Zsave-analysis --error-format=json -Zcontinue-parse-after-error -Zno-trans --sysroot C:\Users\Arnavion\.multirust\toolchains\stable-x86_64-pc-windows-msvc\

If I run that command myself, it succeeds, and I can see C:\Stuff\Sources\rust\target\rls\debug\save-analysis\test.json is created.

But eventually rustls returns this to vscode:

{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///C:/Stuff/Sources/rust/src/main.rs","diagnostics":[{"range":{"start":{"line":0,"character":0},"end":{"line":0,"character":0}},"severity":1,"code":"E0462","message":"found staticlib `std` instead of rlib or dylib"}]}}

Perhaps this is because my default rustup toolchain is stable, not nightly?

[jntrnr]

Definitely sounding like we need url encoding/decoding rather than the "trim off the front" hack I did to get things working.

[nrc]

@Arnavion you will need a nightly compiler I think. Also, @jonathandturner has reported trouble using rustup, so you might need a manually installed one.

[Arnavion]

@jonathandturner Yes, that's why I replaced the hack with Url::from/to_file_path

[Arnavion]

@nrc Uninstalled all toolchains from rustup and installed the Nightly MSI, but ran into #64. Going to reinstall to a path without spaces...

[Arnavion]

It works!

[Arnavion]

So to get everything working:

• Must use the Nightly compiler installed to a path without spaces. Shouldn't be rustup (not even if default rustup toolchain is nightly and rustup install path is without spaces).
  
  
  
  • Latest pathbuf branch contains fix so that paths with spaces will also work.
  
  
  • With latest pathbuf branch, rustup nightly toolchain will also work.
  
  
• The commits from my three branches to rls-analysis, rls-vfs, rustls so that file URLs and paths are handled properly.
• Ensure rustls is compiled against rust-url 1.2.2 or newer so that it has https://github.com/servo/rust-url/pull/231

Will appreciate additional testing.

[nrc]

That all sounds like it is doing the right thing, except for the fact that
there is no save analysis data to read. Is the initial build not happening?
Or is it putting the data somewhere unexpected?

On 21 Oct 2016 7:48 am, "Arnav Singh" [email protected] wrote:

1. I open the folder C:\foo\bar in VSCode.
2. AnalysisHost::reload() is called in response to the diagnosticBegin
   message.
3. Since at this point self.Analysis is still a mutex around None,
   needs_hard_reload is set to true, which calls self.hard_reload
4. hard_reload calls lowering::lower with raw_analysis initiatilized
   by raw::Analysis::read with C:\foo\bar as the path_prefix.
5. raw::Analysis::read calls read_internal which builds a path list
   C:\foo\bar\target\rls\$targetsave-analysis,
   C:\foo\bar\target\rls\$targetdepssave-analysis,
   C:\foo\bar\libssave-analysis. None of these exist; in particular
   C:\foo\bar\target\rls itself doesn't exist.
6. As a result, DirectoryListing::from_path returns an Err for the
   very first path, which means read_incremental returns an empty vector,
   i.e. no crates.
7. Thus lowering::lower has no crates to iterate over, so never calls
   the callback that would've inserted crates into Analysis::per_crate,
   thus that map remains empty.

Subsequently, when AnalysisHost::goto_def is called from
ActionHandler::goto_def:

1. It calls Analysis::def_id_for_span
2. Analysis::def_id_for_span tries to iterate over the crates it has
   with self.for_each_crate, but this map is empty, so it returns None
   which self.read converts into Err(())
3. ActionHandler::goto_def converts this to an empty vector of
   results. Thus the gotodef has no results.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jonathandturner/rustls/issues/54#issuecomment-255194021,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAujArqxDpYKGfMny6-UZWNnd4VIv7j2ks5q17dvgaJpZM4KbKmo
.

[Arnavion]

@nrc Old email that didn't get sent until you got a network connection? :D

[nrc]

@Arnavion yeah, an old email, but I'm pretty sure I've had network for the last 5 days, don't know why it only just registered.

[hban]

I gave the latest master another try, and it looks like this is fixed now! Tooltips and autocomplete also work now (well, mostly).

@Arnavion: I tested this on rustup nightly, dates 2016-10-15 and 2016-10-20. You said that it shouldn't be rustup nightly, but it looks that those issues got fixed in the meantime?

[Arnavion]

@hban

With latest pathbuf branch, rustup nightly toolchain will also work.

:)