rust-analyzer / rust-analyzer.github.io Goto Github PK

In a situation in which a function returns a thiserror error enum and a new error type is used, it would be extremely helpful if Rust Analyzer could recommend adding that error to that enum or otherwise creating a new error type. Done properly this could take the pain out of error type management

The rust-analyzer is the default in ycm, so the link to the installation instruction is outdated
https://rust-analyzer.github.io/manual.html#youcompleteme

ycm-core/lsp-examples@d924041

Hi, the manual says the following about this feature:

You can customize the look of different semantic elements in the source code. For example, mutable bindings are underlined by default and you can override this behavior by adding the following section to your settings.json

However, there doesn't seem to be a way to set this to "normal" - ie turn the feature off. The only options it will accept for that setting are blank - in which case I get underlined text - or variations on bold, italic, strike through etc.

Is there a way to disable this altogether? I personally find different font styles in my source to be really distracting.

Thanks

In the User manual manual.adoc, there is a section to help everyone to set up their favorite IDE/editor. This is great.

I could probably provide a PR for at least two more text editors (Kakoune and Helix).

But first, I wanted to know if this kind of changes would be welcomed. I could understand the desire to keep the list short and only about mainstream IDE/editors. Tell me if you'd like me to contribute or else, you can just close the issue.

For syntax highlighting, jekyll already parses the code and wraps tokens in spans with different CSS classes. All we need is some CSS to set the colors, e.g.

pre.highlight .k { /* keyword */
    color: #0b65ca;
}

The emacs LSP setup documentation in manual#emacs is very of date. It's much simpler then when the instructions were written, no extra packages need to be installed other than installing an LSP client.

Emacs LSP support has grown a lot in the past years. There are two popular language servers: The first one is lsp-mode, which adds a lot of features, support LSP protocol extensions and is a bit bloated, and the lightweight
which eglot, which is more minimal, extends existing emacs functionality and has been merged into the emacs29 branch (which will be the next release).

In both popular language server implementation, rust-analyzer is the default language server for rust and no extra package or customization is required other than installing eglot or lsp-mode and enabling them. I personally prefer eglot, but lsp-mode is still fine. No lsp-rust.el is needed, that has been merged into lsp-mode and is enabled by default. It seems that the linked blog post has been updated and is still valid, so this can be linked for how to setup lsp-mode, though imo it's very opinitioned.

I think it's enough to mention the two lsp client's, what their differences are and link to their respective install/quickstart documentations and maybe a one-liner how they are typically activated

Eglot

(add-hook 'rust-mode-hook #'eglot-ensure)

• github: https://github.com/joaotavora/eglot
• quickstart: https://joaotavora.github.io/eglot/#Quick-Start

LSP-Mode
Activate interactively via M-x lsp or load automatically via

(add-hook 'rust-mode-hook #'lsp-deferred)

• github: https://github.com/emacs-lsp/lsp-mode
• install: https://emacs-lsp.github.io/lsp-mode/page/installation/
• reference for extra rust-analyzer functions: https://emacs-lsp.github.io/lsp-mode/page/lsp-rust-analyzer

Maybe I'll do a PR, but the caveat is that I'm not a rust dev, I just started doing rustlings. But I'm an experience emacs user and following emacs development and I recently switched from lsp-mode to eglot, so kind of know both.

I did my best to faithfully follow defaults to install Rust and Rust Analyzer for WSL/Linux:
https://www.rust-lang.org/learn/get-started
https://code.visualstudio.com/docs/languages/rust

When launched on Debian 11 and Ubuntu 22.04 running in WSL2 I got the following error from the server:

[ERROR rust_analyzer::main_loop] FetchBuildDataError:
Failed to run build scripts for /workspaces/rust-analyzer-repro: No such file or directory (os error 2)

I prepared a dev container with a minimal set of files which reproduces the issue if you are set up to run remote containers:
https://github.com/rfulwell/rust-analyzer-repro

Steps to reproduce:

1. git pull https://github.com/rfulwell/rust-analyzer-repro
2. cd rust-analyzer-repro; code .
3. When prompted, reopen the project in a dev container
4. Open the src/main.rs file and pause while the server processes the file
5. Note the error as above and the status bar message with popup:
   

The most simplified way I was able to find in order to work around the issue is to override three default settings. You can reproduce this by uncommenting the lines in the devcontainer.json file yourself or reverting the last commit in the repo.

So to reproduce the workaround, uncomment these lines and rebuild the dev container:

				// "rust-analyzer.cargo.buildScripts.enable": false,
				// "rust-analyzer.procMacro.attributes.enable": false,
				// "rust-analyzer.procMacro.enable": false

This does not seem to be a blocking issue for the extension but I don't like working with persistent errors in my environment so here we are. 😅

Hello!

In your weekly "Changelog" posts (which I look forward to every Monday), would you consider adding the vscode extension version number? For example, this week the extension version is v0.2.232, but I'm not sure how to derive that version from either the commit hash or the release name. I think this would help users figure out if their vscode extension has been updated yet or not.

Thanks!

Hi...

It seems there may be a memory problem in Windows / vscode...
After it runs for a while I get this:

Image			PID	HFaults/sec	Commit (KB)	Working Set (KB)	Shareable (KB)	Private (KB)
rust-analyzer.exe	2628	0		24,842,288	733,548			12,400		721,148
rust-analyzer.exe	7972	0		13,256,732	47,144			18,668		28,476

It releases when I restart it...

I wrote this:

fn                  test() {
    let a=1;
}

after formatted, I got this:

fn test() {
    let a = 1;
}

that is ok.

but when I wrote this:

async fn                  test() {
    let a=1;
}

fn test2           (){}

after formatted, nothing happen.

version: rust-analyzer v0.3.1301

Looks like this now

Other options aren't documented. Had to search the codebase to find them.

https://github.com/rust-lang/rust-analyzer/blob/4778255b3de9786c59928346470b2ed3cfcdb2c9/editors/code/package.json#L787C16-L787C16

The metrics page doesn't show the time when each commit was benchmarked. Also, it doesn't work properly on mobile. I made a PR to fix this, but apparently the PR has been overlooked.

@matklad @lnicola It would be great if one of you could review the PR. Also, I appreciate the work you put into rust-analyzer, so thank you!

Not sure if this is the right place, this is an issue on the VS Code extension version of this.

If i add a new crate, or add a new part of a crate (like you can with winapi-rs) it's not detected,
even if i build which works and it can be used VS doesn't notice that it exists.

So in order to make it work i have to restart the language server.

[Expected]
Adding crates and building it should make it work like normal
[Reality]
Adding a crate works with building etc, but the analyzing part just doesn't know it's there

I've noticed that rust-analyzer in open-vsx marketplace has been stuck on version 0.2.853 for some time.

What's the official rust-analyzer stance on 3rd party marketplaces for VS-code clone extensions? I'm wondering how best we could get this updated on that marketplace, it's used by a fair amount of people that use OS-code (e.g. any arch linux user).

On https://opencollective.com/rust-analyzer/updates is a broken link to

https://rust-analyzer.github.io/2019/10/16/finance.html

The correct link is

https://rust-analyzer.github.io/blog/2019/10/16/finance.html

It's been a while since the last financial report.

The OpenCollective page says that there are 164,774.60 EUR in the account, and only 22,000 EUR have been withdrawn. Does that mean that donations aren't needed? I think the people donating would appreciate an update to know what will happen with the money.

I've started getting some new toast notifications in the bottom right part of the screen. I personally find them very annoying as every time cargo check fails I get a pop up saying "cargo check failed". I already get the wiggly lines so don't need that distraction

I went through all settings but couldn't find a way to disable them. Could this be added please?

Version: 0.2.554

Hi,

I'm Using DoomEmacs under OpenBSD, it proposes, but fails to install "rustanalyzer" with error:
"/.../rust-analyzer.gz: unrecognized format"

When looking for more details, I found that the problem comes from the fact that the file size is 0b , which is related to the fact there is an automatic download process that compose the URL where to download based on the System's OS name, and this URL/file does not exists.

I triad to download the sources and compile them, but I had too much errors.

If someone can help make the code compile under (Open)BSD, that would be great!

I recently came across the "next few years" blog post. My first question was "when was this written?"⁠. I eventually noticed the date in the URL, but it would be much more accessible to display it somewhere on the page.

In the VS Code and Updates sections of the User Manual are sections with a left column saying :INFORMATION _SOURCE:. This is rendered as a bold lowercase i on GitHub, but not on the website.

Screenshot in Firefox:

VS Code 1.74.1
Rust-analyzer v0.3.1317
Rust 1.65.0

Example below to simulate the issue.
But if I add curly bracket '{ }' on 'fn' 'struct' auto complete works.

Compiling rust-analyzer from source gives me a binary called rust-analyzer.

And yet, the instructions here: https://rust-analyzer.github.io/manual.html#vim talk about a binary ra_lsp_server. Are these one and the same binary?

If so, shouldn't there be just one binary name?

After fixing my rust analyzer install, mouseover doesn't work for showing me the details of what type a variable is. I've tried disabling and reenabling it, and I've also tried reinstalling the rust analyzer executable as well as the extension. What else can I do to fix this?

The footer contains this code:

<a href="{{ '/feed.xml' | prepend: site.baseurl }}" class="footer-link">
  <i class="fa fa-rss"></i> rss
</a>
<a href="https://github.com/rust-analyzer/rust-analyzer.github.io" class="footer-link">
  <i class="fa fa-github"></i> src
</a>
<a href="https://opencollective.com/rust-analyzer/" class="footer-link">
  <i class="fa fa-github"></i> sponsor
</a>

This should display Font Awesome icons, but Font Awesome is currently not included in the website.

Hello,

With a clean installation of VSCode

Visual Studio Code
Version: 1.74.3 (user setup)
Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534
Date: 2023-01-09T16:59:02.252Z (5 days ago)
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.22621
Sandboxed: No

and just rust-lang.rust-analyzer version 0.3.1361 installed, the rename symbol functionality (that is, F2 key) is not working.

I think the website would profit from branding, especially a logo. I'd like to help out with that, if that's okay. I already had a few ideas about a logo, which I uploaded here.

I've removed the wasm demo from this repo, to speedup deployment process.

I've moved the demo to https://github.com/rust-analyzer/rust-analyzer-wasm

We should setup GitHub actions CI on that repo, which builds the demo and publishes it on that repo pages. We should link that page from the current website.

When I attempt to start the rust analyzer server in VSCode through the command palette, I get a command not found error. I've tried reinstalling the extension and I run into the same issue.

I'm trying to disable checking of all targets, and the documentation says the option should be rust-analyzer.check.allTargets, which didn't work. However rust-analyzer.checkOnSave.allTargets (as copied from other GitHub issues: rust-lang/rust-analyzer#10716 (comment)) does work. Is this an error with the generated documentation, or is it some kind of version mismatch between the documentation and the version of rust-analyzer that I'm using?

Please provide clear instructions for version identification for rust-analyzer components in VS Code.

I believe that the "correct" way to identify rust-analyzer as it is used in "my" instance of Visual Code is to View -> Open View -> Output and, there, pick the "Rust Analyzer Client" component from the drop-down.

This then yields the information block below, including the Visual Studio Code extension version (here: 0.3.566-nightly) and some identifier for the rust-analyzer binary (here: rust-analyzer 2021-04-19-66-g70fe7a451) which I gather is subject to tweaking right now (rust-lang/rust-analyzer#8571)

FWIW, while I create this issue here for the website, I wonder whether linking from the VS Code extension's About page directly to such documentation would help? After all, this is a fast-moving project (nightlies, and I see the commit traffic); good version information will help.

INFO [4/21/2021, 6:06:31 AM]: Extension version: 0.3.566-nightly
INFO [4/21/2021, 6:06:31 AM]: Using configuration {
  cargoRunner: null,
  runnableEnv: null,
  inlayHints: {
    enable: true,
    chainingHints: true,
    maxLength: 25,
    parameterHints: true,
    typeHints: true
  },
  updates: { channel: 'nightly', askBeforeDownload: true },
  server: { path: null, extraEnv: null },
  trace: { server: 'off', extension: true },
  debug: {
    engine: 'auto',
    sourceFileMap: {
      '/rustc/<id>': '${env:USERPROFILE}/.rustup/toolchains/<toolchain-id>/lib/rustlib/src/rust'
    },
    openDebugPane: false,
    engineSettings: {}
  },
  assist: {
    importMergeBehavior: 'full',
    importPrefix: 'plain',
    importGroup: true
  },
  callInfo: { full: true },
  cargo: {
    autoreload: true,
    allFeatures: true,
    features: [],
    runBuildScripts: true,
    useRustcWrapperForBuildScripts: true,
    noDefaultFeatures: false,
    target: null,
    noSysroot: false
  },
  checkOnSave: {
    enable: true,
    allFeatures: null,
    allTargets: true,
    command: 'check',
    noDefaultFeatures: null,
    target: null,
    extraArgs: [],
    features: null,
    overrideCommand: null
  },
  completion: {
    addCallArgumentSnippets: true,
    addCallParenthesis: true,
    postfix: { enable: true },
    autoimport: { enable: true }
  },
  diagnostics: {
    enable: true,
    enableExperimental: true,
    disabled: [],
    warningsAsHint: [],
    warningsAsInfo: []
  },
  files: { watcher: 'client', excludeDirs: [] },
  hoverActions: {
    debug: true,
    enable: true,
    gotoTypeDef: true,
    implementations: true,
    run: true,
    linksInHover: true
  },
  lens: {
    debug: true,
    enable: true,
    implementations: true,
    run: true,
    methodReferences: true,
    references: true
  },
  linkedProjects: [],
  lruCapacity: null,
  notifications: { cargoTomlNotFound: true },
  procMacro: { enable: true, server: null },
  runnables: { overrideCargo: null, cargoExtraArgs: [] },
  rustcSource: null,
  rustfmt: { extraArgs: [], overrideCommand: null }
}
INFO [4/21/2021, 6:06:31 AM]: PersistentState: {
  lastCheck: 1618977860393,
  releaseId: 41747331,
  serverVersion: '0.3.566-nightly'
}
INFO [4/21/2021, 6:06:31 AM]: Using server binary at /home/stefan/.config/Code/User/globalStorage/matklad.rust-analyzer/rust-analyzer-x86_64-unknown-linux-gnu
DEBUG [4/21/2021, 6:06:31 AM]: Checking availability of a binary at /home/stefan/.config/Code/User/globalStorage/matklad.rust-analyzer/rust-analyzer-x86_64-unknown-linux-gnu
DEBUG [4/21/2021, 6:06:31 AM]: /home/stefan/.config/Code/User/globalStorage/matklad.rust-analyzer/rust-analyzer-x86_64-unknown-linux-gnu --version: {
  status: 0,
  signal: null,
  output: [ null, 'rust-analyzer 2021-04-19-66-g70fe7a451\n', '' ],
  pid: 3156,
  stdout: 'rust-analyzer 2021-04-19-66-g70fe7a451\n',
  stderr: ''
}

Seems the vscode extension have problem with vscode version 1.50.1. Please write this and supported versions in readme (or a better place which I don't know) so people can upgrade/downgrade they vscode.

It seems that they've been moved to https://github.com/rust-analyzer/rust-analyzer/tree/master/crates/ide_diagnostics/src/handlers

The homepage states:

Note that the project is in alpha status: it is already useful in practice, but can't be considered stable.

This is subjective, but I wouldn't consider ra to be in alpha status: It is very reliable and I haven't had issues due to breaking changes in a very long time.

Furthermore, this paraphraph might sway some people to use the unmaintained RLS extension instead of ra, even though ra is much faster, more reliable and generally better. Therefore I suggest to remove the warning from the home page.

Most people will use ra whether it is stable or not, so the warning isn't that useful: It's informative, but not actionable (due to the lack of a good, stable alternative, except for IntelliJ-Rust which only works in JetBrains products). It would be more useful if the changelogs had a section detailing the breaking changes, though I suspect that it would be empty in most changelogs.

Opinions?

The main page of the Rust Analyzer blog, https://rust-analyzer.github.io/blog, includes the following:

  <link rel="alternate" type="application/rss+xml" title="rust-analyzer"
    href="https://rust-analyzer.github.io//feed.xml">

This is an RSS feed for the change log, not the blog.

I would very much like to follow this blog, but I'm not interested in the change log. Could you provide an RSS feed for the blog posts?

On my system rust-analyzer leaks ca. 100mb per second until (hopefully) killed because of OOM. Using rust 1.77.0 on x86_64-unknown-linux-gnu.
Any suggestions on how to diagnose?

Hi I noticed the following broken links on the website:

• Posts link in header
• Changelog link in header
• The find usages implemented post

https://www.reddit.com/r/rust/comments/1bn7sip/rustanalyzer_changelog_226/kwm12aq/

Rust is not my main working environment, unfortunately. The rust-analyzer extension reports failed to find any projects in the workspace if the workspace is not a Rust workspace. This is slightly annoying and the associated red badge in the status bar is quite distracting.

I've been using rust-analyzer through VSCode and I keep encountering situations where adding a dependency causes some completions to stop working. I've attached the smallest example I could find, where completing the word "info" in main.rs should suggest log::info, and it does if either x11 or clap is removed from the dependencies, but with both dependencies in place, the only suggestions are std::panic::PanicInfo and a bunch of types from x11 whose names end in Info.

I'm using the following versions:

VSCode: 1.58.0 2d23c42a936db1c7b3b06f918cde29561cc47cd6
rust-analyzer extension: 0.2.662
rust-analyzer e5c1c8cf2 2021-07-05 stable
cargo 1.52.0 (69767412a 2021-04-21)
rustc 1.52.1 (9bc8c42bb 2021-05-09)

example.tar.gz

Just making sure it's on your radar @matklad, since I think almost a year has passed since the last financial report.

It always takes me a while to remember what SSR is whenever it is mentioned in a changelog (it also being used as an abbreviated for server-side rendering doesn't help). Could abbreviations like that instead be written in full, or explained somewhere (footnote / small glossary at the top)?

I've been seeing panics like the following, resulting in quick fix and inlay hints breaking, among other things:

thread '<unnamed>' panicked at 'not implemented', /home/bdonlan/.cargo/registry/src/github.com-1ecc6299db9ec823/chalk-solve-0.30.0/src/clauses.rs:59:36
stack backtrace:
   0: std::panicking::begin_panic
   1: chalk_solve::clauses::push_auto_trait_impls
   2: chalk_solve::clauses::builder::ClauseBuilder<I>::push_binders
   3: chalk_solve::clauses::program_clauses_for_goal
   4: chalk_recursive::recursive::Solver<I>::solve_new_subgoal
   5: <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal
   6: <chalk_recursive::recursive::RecursiveSolver<I> as chalk_solve::solve::Solver<I>>::solve_limited
   7: hir_ty::traits::trait_solve_query
   8: salsa::runtime::Runtime::execute_query_implementation
   9: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  10: salsa::derived::slot::Slot<Q,MP>::read
  11: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  12: <DB as hir_ty::db::HirDatabase>::trait_solve::__shim
  13: <DB as hir_ty::db::HirDatabase>::trait_solve
  14: hir_ty::infer::InferenceContext::resolve_ty_as_possible
  15: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
  16: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::check_call_arguments
  17: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_method_call
  18: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  19: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  20: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  21: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
  22: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_inner
  23: hir_ty::infer::expr::<impl hir_ty::infer::InferenceContext>::infer_expr_coerce
  24: hir_ty::infer::infer_query
  25: salsa::runtime::Runtime::execute_query_implementation
  26: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  27: salsa::derived::slot::Slot<Q,MP>::read
  28: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  29: <DB as hir_ty::db::HirDatabase>::infer_query::__shim
  30: hir_ty::db::infer_wait
  31: hir::source_analyzer::SourceAnalyzer::new_for_body
  32: hir::semantics::SemanticsImpl::analyze2
  33: hir::semantics::SemanticsImpl::type_of_pat
  34: ide::inlay_hints::inlay_hints
  35: std::panicking::try
  36: ide::Analysis::inlay_hints
  37: rust_analyzer::handlers::handle_inlay_hints
  38: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

It looks at first glance like updating chalk to 0.32.0 might fix this, but it's a bit nontrivial as there are some incompatible changes to traits that were made as well.