Sourcegraph have a beta version of an lsp client, here. I've set it up and configured it, and I've got rls (https://github.com/rust-lang-nursery/rls/commit/e24fc84bfc4b3360a3d65d9adeab0f701140094d, on Nightly 6f10e2f63) running too. Predictably, it's not working yet, but it looks like:

• sublime-lsp is sending data to rls
• it's getting responses

What are some next steps to figure out where the current incompatibilities are?

Sample request: Action: hovering over .to_vec(), in a file at /Users/sth/dev/rust-geo/src/algorithm/simplifyvw.rs

This sends (visible from the sublime-lsp debug log in the console):

[
    'Content-Length: 259',
    '',
    '{',
    '  "method": "textDocument/hover", ',
    '  "params": {',
    '    "position": {',
    '      "character": 23, ',
    '      "line": 53',
    '    }, ',
    '    "textDocument": {',
    '      "uri": "file:///Users/sth/dev/rust-geo/src/algorithm/simplifyvw.rs"',
    '    }',
    '  }, ',
    '  "jsonrpc": "2.0", ',
    '  "id": 27',
    '}'
]

And receives the response:

{
    'result': {
        'range': None,
        'contents': []
    },
    'jsonrpc': '2.0',
    'id': 27
}

I've configured the User settings for Sublime-lsp as follows:

{
    "clients": [
        {
            "binary": "rls",
            "file_exts": ["rs"],
            "path_additions": [
                "/users/sth/dev/rls/target/release/",
                "/Users/sth/.rustup/toolchains/nightly-x86_64-apple-darwin/lib"
            ],
            "env": {
                "DYLD_LIBRARY_PATH": "/Users/sth/.rustup/toolchains/nightly-x86_64-apple-darwin/lib",
                "RLS_ROOT": "/users/sth/dev/rls/target/release/rls"
            }
        }
    ]
}

(I've also set up DYLD_LIBRARY_PATH and RLS_ROOT in my .bashrc)

It just crashes on any project in Ubuntu 16.04. Chatted about it in #rust-tools with @jonathandturner and it seems it has something to do with latest rustup release.

After updating to 1.23.0-nightly (d9f124965 2017-10-27) I am receiving the error below when attempting to install RLS on Linux (nightly-x86_64-unknown-linux-gnu) and Windows (nightly-x86_64-pc-windows-msvc).

$ rustup component add rls-preview --toolchain nightly

error: toolchain 'nightly-x86_64-unknown-linux-gnu' does not contain component 'rls-preview' for target 'x86_64-unknown-linux-gnu'

Running 'rls' triggers this error:

$ rls

error: toolchain 'nightly-x86_64-unknown-linux-gnu' does not have the binary `rls`

A similar problem was reported last month under Issue 502, when the component was renamed from 'rls' to 'rls-preview'.

For me neither running 'rustup self update' nor uninstalling & reinstalling rustup resolved the issue.

When I use RLS with alacritty I get this error "E0463 can't find crate for alacritty can't find crate".

Is this supposed to work?

If I add build_lib: true to an rls.toml file I don't get any warnings at all in main.rs.

I'm on latest master of rls and LanguageClient-neovim

The file paths returned by rls-analysis are relative to the current working directory, while racer returns absolute paths.

Take this simple code snippet for instance, assuming it'd be located at /Users/username/project:

use std::io;

fn main() {
    let _ = io::stdin();
}

If you try to go to the definition of io (the one inside the main function) it works, because rls falls back to racer here, which returns the full absolute path to the Rust source file:

INFO:rls::actions: goto_def - falling back to Racer
DEBUG:rls::server: response: "Content-Length: 232\r\n\r\n{\"jsonrpc\":\"2.0\",\"id\":40,\"result\":[{\"uri\":\"file:///Users/username/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/net/mod.rs\",\"range\":{\"start\":{\"line\":0,\"character\":1},\"end\":{\"line\":0,\"character\":1}}}]}"

Formatted:

{
  "jsonrpc": "2.0",
  "id": 40,
  "result": [
    {
      "uri": "file:///Users/username/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/src/libstd/net/mod.rs",
      "range": {
        "start": {
          "line": 0,
          "character": 1
        },
        "end": {
          "line": 0,
          "character": 1
        }
      }
    }
  ]
}

If however you try to go to the definition of stdin it won't work:

DEBUG:rls::server: response: "Content-Length: 187\r\n\r\n{\"jsonrpc\":\"2.0\",\"id\":76,\"result\":[{\"uri\":\"file:///Users/username/project/src/libstd/io/stdio.rs\",\"range\":{\"start\":{\"line\":204,\"character\":7},\"end\":{\"line\":204,\"character\":12}}}]}"

Formatted:

{
  "jsonrpc": "2.0",
  "id": 76,
  "result": [
    {
      "uri": "file:///Users/username/project/src/libstd/io/stdio.rs",
      "range": {
        "start": {
          "line": 204,
          "character": 7
        },
        "end": {
          "line": 204,
          "character": 12
        }
      }
    }
  ]
}

See how the path is now relative to my project root, where VSCode as well as rls were spawned in?

I tried understanding and possibly fixing rls-analysis (where the bug should be at I believe), however I was unable to find the cause in a reasonable time frame. It'd be nice if someone could fix this issue or help me fix it myself. 🙂

rls-preview 0.130.5 (1c755ef 2018-10-20) rustc nightly-2018-10-28

Ctrl-click and ctrl-hover no longer work, at all. "result" is always []

LSP4E to org.eclipse.corrosion.rls:{"jsonrpc":"2.0","id":"1006","method":"textDocument/definition","params":{"textDocument":{"uri":"***/src/render.rs"},"uri":"***/src/render.rs","position":{"line":92,"character":52}}}
org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":1006,"result":[]}

UPDATE:

• Toolchain nightly-2018-09-20 is unaffected
• Toolchain nightly-2018-10-17 is unaffected
• Toolchain nightly-2018-10-20 is affected
• Toolchain nightly-2018-10-28 is affected
• Toolchain nightly-2018-11-14 is affected
• Toolchain nightly-2018-11-20 is in some cases affected

Replicated in https://github.com/eclipse/corrosion:

• open any project
• 'Ctrl+Click` to navigate to a library source file (contained in .cargo)
• browse

Additional information:

• I have manually added Cargo.toml to .cargo, doesn't fix this
• after this error message the Eclipse IDE freezes (@mickaelistria), probably because it waits for a response from RLS
• pkill rls restores the IDE to an unstable state which constantly re-triggers an RLS build
• it is possible to save the edits and restart the IDE
• on IDE restart, build is constantly re-triggered until all editor tabs are closed

[t=1554109173638] org.eclipse.corrosion.rls to LSP4E:
{"jsonrpc":"2.0","method":"window/progress","params":{"id":"progress_0","title":"Indexing"}}
[t=1554109173638] LSP4E to org.eclipse.corrosion.rls:
{"jsonrpc":"2.0","id":"2","method":"textDocument/codeLens","params":{"textDocument":{"uri":"file:[...]/.cargo/[...]"}}
}
[t=1554109173638] org.eclipse.corrosion.rls to LSP4E:
{"jsonrpc":"2.0","method":"window/showMessage","params":{"message":"could not find `Cargo.toml` in `/` or any parent directory","type":1}}
[t=1554109173638] LSP4E to org.eclipse.corrosion.rls:
Content-Length: 3864

Tracking issue for Atom support.

Existing work: https://github.com/aergonaut/languageserver-rust and https://github.com/mehcode/atom-ide-rust

Checklist (from clients.md):

• [x] Implement extensions to the protocol
• [ ] Client-side configuration.
• [ ] send the workspace/didChangeConfiguration notification when configuration changes.
• [ ] Support all config options, see config.rs
• [x] Check for and install the RLS
• [x] check the RLS is installed, and if not, install it and the rust-analysis and rust-src components
• [ ] be aware that the RLS component is changing name - currently rls, will become rls-preview.
• [ ] you should provide a way to update the RLS component
• [ ] Client-side features
• [ ] e.g., code snippets, build tasks, syntax highlighting
• [ ] Testing
• [x] Ensure integration with existing Rust features, e.g., syntax highlighting
• [ ] 'Marketing'
• [ ] documentation - users need to know how to install and use the extension
• [ ] keep us informed about status so we can advertise it appropriately
• [ ] update the RLS website
• [x] submit the extension to the editor package manager or marketplace

I have been trying to get the RLS working on mdBook for some time now. It just never gets past "RLS analysis: working ◐".

I tried running vscode with the following command, as suggested:

RUST_LOG=rls_analysis=info code

But it never outputs anything. I also tried with and without setting "rust.build_lib": true because I have a project containing both. But unfortunately that didn't work. I can reproduce this on both my mac and my linux pc.

The thing is, though, that the vscode-rust extension with RLS enabled can cope with my project without any trouble. Giving me auto-completion, linting as I type, etc. So to me, it seems like the RLS can work with the project, but somehow the official Rust extension does something different that makes it fail or hang.

Can I do something else to try and debug this? Does anyone have a clue as to why this could happen?

I have imported the whole of .cargo as a project in Eclipse Corrosion - textDocument/hover seems to work for the entries but textDocument/definition doesn't (so Ctrl+click for quick navigation doesn't work)

LSP4E to org.eclipse.corrosion.rls:{"jsonrpc":"2.0","id":"229","method":"textDocument/definition","params":{"textDocument":{"uri":"file:///home/nico/.cargo/registry/src/github.com-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs"},"uri":"file:///home/nico/.cargo/registry/src/github.com-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs","position":{"line":286,"character":17}}}
org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":229,"result":[]}
LSP4E to org.eclipse.corrosion.rls:Content-Length: 327


LSP4E to org.eclipse.corrosion.rls:{"jsonrpc":"2.0","id":"230","method":"textDocument/hover","params":{"textDocument":{"uri":"file:///home/nico/.cargo/registry/src/github.com-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs"},"uri":"file:///home/nico/.cargo/registry/src/github.com-1ecc6299db9ec823/log4rs-0.8.0/src/config.rs","position":{"line":286,"character":17}}}
org.eclipse.corrosion.rls to LSP4E:{"jsonrpc":"2.0","id":230,"result":{"contents":[{"language":"rust","value":"appenders: Vec<Appender>"}]}}

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?

rls has been superseded by rust-analyzer (as marked in README.md), and last commit is from august 2022.

Please archive this (rls) repository to make it obvious at first sight that it is now unmaintained.

• feat: update lsp_types to the latest version:
  • This required adding some optional fields
  • Updating the progress reporter
  • Using u32 in some places instead of u64
  • Passing the correct type as the request/response
  • Changing the enum field cases to upper case

After debugging the code for some time, I cannot find the reason why the 9 remaining tests are failing. Any help would be appreciated.

using this in the find_impls test seems to fix the issue, but modifying the tests like this looks random to me.

                work_done_progress_params: WorkDoneProgressParams {
                    work_done_token: Some(NumberOrString::String("progress_1".to_owned())),
                },

cc: @Xanewok

rls version:

$ rls --version
rls 1.41.0 (bf88026 2021-09-07)

nvim-lspconfig https://github.com/neovim/nvim-lspconfig.git

I am getting this warning in lsp.log

[WARN][2022-02-16 15:10:07] ...lsp/handlers.lua:107 "The language server rls triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
[WARN][2022-02-16 15:10:07] .../lua/vim/lsp.lua:711 "server_request: no handler found for"  "client/unregisterCapability" 

After this, list references for symbols is not working.

Build is working again but the test_tooltip_std is failing (https://github.com/rust-lang/rls/actions/runs/1702875684). Some tooltips are missing from the actual output (❌):

✅: Test { file: "test_tooltip_std.rs", line: 8, col: 15 }
❌: Test { file: "test_tooltip_std.rs", line: 8, col: 27 }
✅: Test { file: "test_tooltip_std.rs", line: 9, col: 7 }
❌: Test { file: "test_tooltip_std.rs", line: 9, col: 12 }
✅: Test { file: "test_tooltip_std.rs", line: 10, col: 12 }
✅: Test { file: "test_tooltip_std.rs", line: 10, col: 20 }
❌: Test { file: "test_tooltip_std.rs", line: 11, col: 25 }
❌: Test { file: "test_tooltip_std.rs", line: 12, col: 33 }
✅: Test { file: "test_tooltip_std.rs", line: 13, col: 11 }
✅: Test { file: "test_tooltip_std.rs", line: 13, col: 18 }
✅: Test { file: "test_tooltip_std.rs", line: 14, col: 24 }
❌: Test { file: "test_tooltip_std.rs", line: 15, col: 17 }
❌: Test { file: "test_tooltip_std.rs", line: 15, col: 25 }

I took a look at it but I'm not familiar enough with the code to know what might cause this. I'm also not really sure why the triggered CI succeeds (scheduled CI fails)---my local build is always failing these tests. The scheduled CI is also failing test_tooltip_std_racer but that seems to pass for me locally.

Locally, the rest of the tests are all passing so this is the last thing to fix right now

The README says to pin to a specific version found at https://rust-lang.github.io/rustup-components-history/ – however, that site only shows the last 7 days. It currently (at time of writing: 2022-01-10) does not even list "rls" anywhere, likely because no recent RLS builds are available for the nightly toolchain. Thus, I had to trick around like this

for n in $(seq 10 30); do if rustup toolchain add nightly-2021-11-${n} -c rls; then break; fi; done

in order to find that the latest available toolchain with RLS was 2021-11-09 at the time.

Other, more obvious solutions such as finding the latest successful CI build (linked from the button in the README: https://github.com/rust-lang/rls/actions?query=workflow%3ACI+branch%3Amaster) did not work for me, likely because their date does not necessarily relate directly to the (nightly) toolchain release date.

Having to pin a version isn't super bad, but then users should be given better hints how to solve it. Modern Rust projects often require nightly builds, so having RLS is essential for developer experience.