rust-analyzer is a modular compiler frontend for the Rust language

Related tags

IDEs rust lsp-server

rust-analyzer logo

rust-analyzer is a modular compiler frontend for the Rust language. It is a part of a larger rls-2.0 effort to create excellent IDE support for Rust.

Work on rust-analyzer is sponsored by

Ferrous Systems

Quick Start


If you want to contribute to rust-analyzer or are just curious about how things work under the hood, check the ./docs/dev folder.

If you want to use rust-analyzer's language server with your editor of choice, check the manual folder. It also contains some tips & tricks to help you be more productive when using rust-analyzer.

Security and Privacy

See the corresponding sections of the manual.


For usage and troubleshooting requests, please use "IDEs and Editors" category of the Rust forum:

For questions about development and implementation, join rust-analyzer working group on Zulip:

Quick Links


Rust analyzer is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).


  • "cargo metadata failed: No such file or directory (os error 2)"

    I'm trying to work on a project that the RLS extension has no problem handling but I'm getting an odd error from rust-analyzer that is pretty unhelpful:

    rust-analyzer failed to load workspace: cargo metadata failed: No such file or directory (os error 2)

    What file or directory could not be found? Why couldn't it be found even though RLS works without a hitch?

    I'm running the VSCode extension remotely (Docker) with VSCode Insiders and rust-analyzer at commit 759100fb0dcb41518f2a593dae5de5bbedd07776.

    opened by samuela 66
  • rust-analyzer is slow to compile

    rust-analyzer is slow to compile

    Both ra_hir and ra_ide_api are really slow to compiler, which makes fix & test loop rather frustrating. Note that tests are extremely fast themselves, it's compile time that hurts us badly.

    We need to do something with it...

    E-hard fun 
    opened by matklad 58
  • Theme loading and

    Theme loading and "editor.tokenColorCustomizations" support.

    Fixes: Issue#1294


    • [x] Load themes
    • [x] Load existing ralsp-prefixed overrides from "workbench.colorCustomizations".
    • [x] Load overrides from "editor.tokenColorCustomizations.textMateRules".
    • [x] Use RA tags to load vscode.DecorationRenderOptions (colors) from theme & overrides.
    • [x] Map RA tags to common TextMate scopes before loading colors.
    • [x] Add default scope mappings in extension.
    • [x] Cache mappings between settings updates.
    • [x] Add scope mapping configuration manifest in package.json
    • [x] Load configurable scope mappings from settings.
    • [x] Load JSON Scheme for text mate scope rules in settings.
    • [x] Update Readme.

    Borrowed the theme loading (scopes.ts) from Tree Sitter with some modifications to reading "editor.tokenColorCustomizations" for merging with loaded themes and had to remove the async portions to be able to load it from settings updates.

    ~Just a PoC and an idea I toyed around with a lot of room for improvement.~ For starters, certain keywords aren't part of the standard TextMate grammar, so it still reads colors from the ralsp prefixed values in "workbench.colorCustomizations".

    But I think there's more value making the extension work with existing themes by maping some of the decoration tags to existing key or keys.

    Screenshot 2019-11-09 at 17 43 18 Screenshot 2019-11-09 at 17 41 45 Screenshot 2019-11-09 at 17 40 29

    These will merge with the default ones coming with the extension, so you don't have to implement all of them and works well with overrides defined in settings.

        "editor.tokenColorCustomizations": {
            "textMateRules": [
                    "scope": "keyword",
                    "settings": {
                        "fontStyle": "bold",

    Edit: The idea is to work with 90% of the themes out there by working within existing scopes available that are generally styled. It's not to say I want to erase the custom Rust scopes - those should still remain and eventually worked into a custom grammar bundle for Rust specific themes that target those, I just want to make it work with generic themes offered on the market place for now.

    A custom grammar bundle and themes for Rust specific scopes is out of... scope for this PR. We'll make another round to tackle those issues.

    Current fallbacks implemented

        ['string', ['string']],
        ['keyword', ['keyword']],
        ['keyword.control', ['keyword.control', 'keyword', 'keyword.other']],
            ['storage.modifier', 'keyword.other', 'keyword.control', 'keyword']
        ['function', ['']],
        ['parameter', ['variable.parameter']],
        ['constant', ['constant', 'variable']],
        ['type', ['']],
        ['builtin', ['variable.language', 'support.type', 'support.type']],
        ['text', ['string', 'string.quoted', 'string.regexp']],
        ['attribute', ['keyword']],
        ['literal', ['string', 'string.quoted', 'string.regexp']],
        ['macro', ['support.other']],
        ['variable', ['variable']],
        ['variable.mut', ['variable', 'storage.modifier']],
        ['module', ['', 'entity.other']]
    opened by seivan 57
  • [WIP] ra-fmt

    [WIP] ra-fmt

    Struct EditTree will more directly mutate the syntax tree by building up nodes with knowledge of Pattern's, checking as we walk the tokens and inserting edits marked with location and other meta info. When a diff is asked for the tree will know the amount, size and type of edit capable of producing a diff. relevant files: edit_tree the new way to directly mutate tree scratch just to get something to output to see what I'm doing otherwise everything so far is similar or stolen from nixpkgs-fmt :smile:

    Would it make sense for rowan node's to be able to insert tokens, or is keeping a vec of edits to create a diff which some other thing can interpret and build the appropriate string out of more the direction to go in.

    opened by DevinR528 52
  • Unresolved import for platform specific modules

    Unresolved import for platform specific modules

    I tried to search if it was reported but didn't found anything.

    When importing the platform specific modules in std::os rust-analyzer gives me the following error: unresolved import. Also those modules don't show up for auto-complete.

    When the module is used outside use statement, there is no error, but the semantic token are of the type unresolvedReference.

    RA version

    Latest master branch


    use std::os::unix;
    E-hard S-unactionable 
    opened by GrayJack 50
  • rust-analyzer failed to load workspace

    rust-analyzer failed to load workspace

    I installed rust with brew on MacOS, and I'm noticing this error on a hello world project with VS Code:

    rust-analyzer failed to load workspace: 
        Failed to find sysroot for Cargo.toml file ./rust_new/Cargo.toml. 
        Is rust-src installed?: rustup component add rust-src failed

    I didn't install with rustup, and I figured I wouldn't need to. This suggests I must, but why? Does this suggest I need the complier source to use your package in my editor?

    opened by Redoubts 46
  • proc macro server crashed

    proc macro server crashed

    rust-analyzer version: b82458818 2021-05-17 stable

    After rustup update and maybe a new version of ra I get this error: 'proc macro returned error: proc-macro panicked: range end index 8 out of range for slice of length 0'. stack backtrace:

    thread 'main' panicked at 'range end index 8 out of range for slice of length 0', crates/proc_macro_srv/src/proc_macro/bridge/
    stack backtrace:
       0: rust_begin_unwind
                 at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/
       1: core::panicking::panic_fmt
                 at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/
       2: core::slice::index::slice_end_index_len_fail
                 at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/slice/
       3: <proc_macro_srv::proc_macro::bridge::server::Dispatcher<proc_macro_srv::proc_macro::bridge::server::MarkedTypes<S>> as proc_macro_srv::proc_macro::bridge::server::DispatcherTrait>::dispatch
       4: <proc_macro_srv::proc_macro::bridge::closure::Closure<A,R> as core::convert::From<&mut F>>::from::call
       5: proc_macro::bridge::closure::Closure<A,R>::call
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
       6: proc_macro::bridge::client::Literal::integer::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
       7: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::with::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
       8: proc_macro::bridge::client::BridgeState::with::{{closure}}::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
       9: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      10: proc_macro::bridge::client::BridgeState::with::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      11: std::thread::local::LocalKey<T>::try_with
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/thread/
      12: std::thread::local::LocalKey<T>::with
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/thread/
      13: proc_macro::bridge::client::BridgeState::with
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      14: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::with
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      15: proc_macro::bridge::client::Literal::integer
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      16: proc_macro::Literal::i64_unsuffixed
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/
      17: proc_macro2::imp::Literal::i64_unsuffixed
                 at /home/nick/.cargo/registry/src/
      18: proc_macro2::Literal::i64_unsuffixed
                 at /home/nick/.cargo/registry/src/
      19: syn::expr::printing::<impl quote::to_tokens::ToTokens for syn::expr::Index>::to_tokens
                 at /home/nick/.cargo/registry/src/
      20: derive_more::add_helpers::tuple_exprs
                 at /home/nick/.cargo/registry/src/
      21: derive_more::add_assign_like::expand
                 at /home/nick/.cargo/registry/src/
      22: derive_more::add_assign_derive
                 at /home/nick/.cargo/registry/src/
      23: core::ops::function::FnOnce::call_once
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/core/src/ops/
      24: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      25: proc_macro::bridge::client::run_client::{{closure}}::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      26: proc_macro::bridge::scoped_cell::ScopedCell<T>::set::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      27: proc_macro::bridge::scoped_cell::ScopedCell<T>::replace
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      28: proc_macro::bridge::scoped_cell::ScopedCell<T>::set
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      29: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      30: std::thread::local::LocalKey<T>::try_with
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/thread/
      31: std::thread::local::LocalKey<T>::with
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/thread/
      32: proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      33: proc_macro::bridge::client::run_client::{{closure}}
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      34: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/
      35: std::panicking::try::do_call
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/
      36: __rust_try
      37: std::panicking::try
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/
      38: std::panic::catch_unwind
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/std/src/
      39: proc_macro::bridge::client::run_client
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      40: proc_macro::bridge::client::Client<fn(proc_macro::TokenStream) .> proc_macro::TokenStream>::expand1::run
                 at /rustc/5dc8789e300930751a78996da0fa906be5a344a2/library/proc_macro/src/bridge/
      41: proc_macro_srv::proc_macro::bridge::server::<impl proc_macro_srv::proc_macro::bridge::client::Client<fn(proc_macro_srv::proc_macro::bridge::client::TokenStream) .> proc_macro_srv::proc_macro::bridge::client::TokenStream>>::run
      42: proc_macro_srv::cli::run
      43: rust_analyzer::main
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
    thread panicked while processing panic. aborting.
    [ERROR proc_macro_api::process] proc macro server crashed, server process state: Ok(Some(ExitStatus(ExitStatus(132)))), server request error: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" 

    Here's a minimal example:

    For me it looks like this: image ... but runs fine:

    [email protected] /m/d/c/ra-proc-macro (main)> cargo r
    warning: field is never read: `leg`
     --> src/
    4 |     leg: &'a str,
      |     ^^^^^^^^^^^^
      = note: `#[warn(dead_code)]` on by default
    warning: 1 warning emitted
        Finished dev [unoptimized + debuginfo] target(s) in 0.00s
         Running `target/debug/ra-proc-macro`
    Hello, world!
    A-macro S-actionable 
    opened by NickNick 42
  • Missing validators

    Missing validators


    • [x] String
    • [x] Char
    • [x] Byte
    • [x] ByteString
    • [ ] RawString
    • [ ] RawByteString
    • [ ] Integers
    • [ ] Floats


    • [ ] /* comments have a closing */
    • [ ] Doc comments are attached to nodes
    good first issue E-easy E-has-instructions 
    opened by aochagavia 41
  • unresolved import: `thiserror::Error`

    unresolved import: `thiserror::Error`

    In the latest version of rust-analyzer (on nvim+coc, but a coworker is reporting the same thing on VSCode), I'm getting the following error from rust-analyzer.


    [rust-analyzer] [E] unresolved import

    This happens even though a regular build of the project finishes just fine.

    thiserror::Error is a derive macro without an accompanying trait (c.f. serde::Serialize, which is a derive macro and also a trait, which does not cause an error).

    Could there be a regression with importing derive macro traits?

    E-unknown S-actionable 
    opened by bryanburgers 40
  • cargo check output not showing up

    cargo check output not showing up

    After upgrading to 0.2.166 I no longer see cargo check output in the edit pane.

    The extension now runs cargo check almost immediately after each edit (and not just upon save) which is good because that cargo check comes back quickly enough.

    However, none of the errors, including clippy warnings, are showing up. They are just silently swallowed.

    I have to manually run cargo check on the command line and manually Ctrl-Click each error position to get there. The errors are no longer red-underlined. I wonder what has happened.

    opened by schungx 38
  • Feature request: Inline type alias

    Feature request: Inline type alias

    Similar to "Inline function" / "Inline into all callers", it would be nice if there was "Inline typealias" and "Inline into all uses" for type aliases.

    S-actionable A-assists C-feature 
    opened by jplatte 0
  • Add a FixIt to generate documentation templates

    Add a FixIt to generate documentation templates

    This FixIt would allow to generate a documentation template containing sections according to above an undocumented public function.

    The goal is not to generate the whole documentation for a function, it is just to guide the author documenting the function.


    fn myfunction(a: i32, b: SomeRandomType) -> Result<OtherRandomType> { ... }

    Would generate

    /// # Example
    /// ```rust
    /// # use mycrate::myfunction
    /// let b;
    /// let result = myfunction(a, b);
    /// let expected;
    /// assert_eq!(expected, result);
    /// ```
    /// # Errors
    /// This function will return an error if 

    A few specifications are written below. They are not exhaustive and need discussion.


    It would always contain an # Example section, adding a pre-filled snippet of code calling the function.

    • Arguments (including self) would be declared first (except for trivial types), without initialization to let the author give a relevant value to the argument. Borrowing and mutability would be managed (for instance a fn function(&mut self) would generate something like let mut something; where "something" can be the sneaky_cased name of the Type implemented, see the item below.
    • The default name for arguments would be the same name as the argument except for self where the name in the generated example would be the sneaky_cased name of the Type implemented.
    • [Discussion needed] The default name for the returned value would be result except for Self where the name in the generated example would be the sneaky_cased name of the Type implemented.
    • For an unsafe function, the function call would be put into an unsafe block.
    • The function call would be followed by an assert_eq! if it returns a value, to check the returned value.
    • The function call would be followed by an assert_eq! if it takes an &mut argument to check the new value of the argument.
    • If the function returns something
      • if the function is safe and the return type is trivial and the function has less than X arguments, the function is put directly as the second argument of assert_eq!
      • else the function is the RHS of a let, and another let is added to define the expected result.

    For instance in the crate mycrate, the following function:

    fn myfunction(a: i32, b: SomeRandomType) -> OtherRandomType { ... }

    would generate the following example:

    # use mycrate::myfunction
    let b;
    let result = myfunction(a, b);
    let expected;
    assert_eq!(expected, result);


    • If the return type of the function is Result<_>, an # Errors section would be added
    • If the function is unsafe, a # Safety section would be added
    • [Discussion needed] If the function contains an .unwrap(), .expect() or panic!(), a # Panics section would be added. (It would be nice to guess if the function may panic because of inappropriate input or state.)


    • [ ] In the generated example, a type being trivial or not can be discussed (for instance if T is a primitive type, T and Option<T> could be considered trivial).
    • [ ] In the generated example, the maximal number of arguments before the function call is moved out of the assert_eq! macro should be discussed (for instance 2 or 3)
    • [ ] In the generated example, maybe the arguments could be defined for instance if the type is Default or has a ::new() function.
    • [ ] In the generated example, when the function call is moved out of the assert_eq!, the name of the returned value should be discussed.
    • [ ] When to add a # Panics section?

    Comments appreciated :smiley:

    S-actionable A-assists C-feature 
    opened by numero-744 0
  • feat: make hightlighting linear

    feat: make hightlighting linear

    In, we've noticed that AstIdMap does a linear lookup when going from SyntaxNode to Id. This leads to accidentally quadratic overall performance. Replace linear lookup with a O(1) hashmap lookup.

    Future work: don't duplicate SyntaxNodePtr in AstIdMap and switch to "call site dependency injection" style storage (eg, store a HashSet<ErasedFileAstId>).

    See the explanation of the work here on YouTube :-)

    As you can see from then benchmark results, this doesn't actually make analysis stats fastre. I am a bit mystified as to why this is happening to be honest.


    Database loaded:     598.40ms, 304minstr, 118mb (metadata 390.57ms, 21minstr, 841kb; build 111.31ms, 8764kinstr, -214kb)
      crates: 39, mods: 824, decls: 18647, fns: 13910
    Item Collection:     9.70s, 75ginstr, 377mb
      exprs: 382426, ??ty: 387 (0%), ?ty: 285 (0%), !ty: 145
    Inference:           43.16s, 342ginstr, 641mb
    Total:               52.86s, 417ginstr, 1018mb

    This PR:

    Database loaded:     626.34ms, 304minstr, 118mb (metadata 416.26ms, 21minstr, 841kb; build 113.67ms, 8750kinstr, -209kb)
      crates: 39, mods: 824, decls: 18647, fns: 13910
    Item Collection:     10.16s, 75ginstr, 389mb
      exprs: 382426, ??ty: 387 (0%), ?ty: 285 (0%), !ty: 145
    Inference:           44.51s, 342ginstr, 644mb
    Total:               54.67s, 417ginstr, 1034mb

    I think we probably should merge the first commit here, but not the second.

    opened by matklad 2
  • ide_db: build symbol index from crate def map

    ide_db: build symbol index from crate def map

    Trying to solve #4842

    Is this looking correct? :eyes:

    • [x] build the symbol index based upon the CrateDefMap for the given crate in crate_symbols
      • [x] make it multi threaded again, and figure out how to cache each moduleid's symbol index in salsa.
      • [x] NavigationTarget for names in macros is wrong, need to figure out how to compute a text range in the original file id?
      • [x] cleanup some duped code
      • [ ] collect macros from ItemScope.macros
      • [ ] do something about SymbolIndex::for_files - ideally it should use the new module symbol index stuff.
        • [ ] delete source_file_to_file_symbols & co...
      • [ ] fix failing test: navigation_target::tests::test_nav_for_symbol - notably the crate def map doesn't seem to find declarations inside function.
    opened by jhgg 1
  • Respect `http.proxyStrictSSL`

    Respect `http.proxyStrictSSL`

    Closes #10866

    Currently untested.

    opened by lnicola 0
  • ra: fix rustfmt custom command not using correct directory

    ra: fix rustfmt custom command not using correct directory

    fixes #10826

    when a custom command is provided, we don't set the working directory to match that of the file we're formatting, thus removing rustfmt's ability to detect the appropriate rustfmt.toml for said file.

    opened by jhgg 1
  • Latest release breaks on .collect() invocation

    Latest release breaks on .collect() invocation

    I've created the following reproduction and confirmed that this seems to break when i run rust-analyzer version: 183ef048f 2021-11-22 stable.

    Meanwhile it does seems to work on rust-analyzer version: 73668334f 2021-11-15 stable.

    1. Create new crate: cargo new hello_world --bin
    2. Fill with:
    use std::{
        fs::{self, DirEntry, File},
        io::{self, Read},
    #[derive(Debug, Clone)]
    struct BootInfo {
        pub id: String,
        pub idx: u32,
        pub start_time: String,
        pub end_time: String,
    fn find_boots() -> io::Result<HashMap<String, BootInfo>> {
        let mut res: HashMap<String, BootInfo> = HashMap::new();
    fn gg() -> io::Result<()> {
        let boots = find_boots()?;
        let foo = boots.values().cloned().collect::<Vec<BootInfo>>();
        println!("{:?}", foo);
    fn main() {
    1. Inline typehits and hover types missing after .collect::<Vec<BootInfo>>(); in line 24:

    Screenshot 2021-11-26 at 14 17 05

    opened by NinnOgTonic 3
  • VS Code extension installation error: unable to verify the first certificate

    VS Code extension installation error: unable to verify the first certificate

    Hi there, I tried installing rust-analyzer extension via remote SSH in vscode behind a corporate proxy. But it failed with such message:

    ERROR [11/26/2021, 9:29:50 AM]: Bootstrap error [st [FetchError]: request to failed, reason: unable to verify the first certificate
    	at ClientRequest.<anonymous> (/home/me/.vscode-server/extensions/matklad.rust-analyzer-0.2.826/out/main.js:39:48367)
    	at ClientRequest.emit (events.js:315:20)
    	at TLSSocket.socketErrorListener (_http_client.js:469:9)
    	at TLSSocket.emit (events.js:315:20)
    	at emitErrorNT (internal/streams/destroy.js:106:8)
    	at emitErrorCloseNT (internal/streams/destroy.js:74:3)
    	at processTicksAndRejections (internal/process/task_queues.js:80:21)] {
      type: 'system',

    I have set http.proxyStrictSSL to false and http.proxy properly, and don't have problem with installing other extensions. My git and cargo both work fine from cmdline. Github API (the above url) is reachable as well. What could be the problem here? Thanks a lot in advance!

    A-vscode S-actionable C-feature 
    opened by tumluliu 11
  • Worked issue #10446 hide

    Worked issue #10446 hide "obvious" inlays

    The suggested method in the issue didn't work because that code path appears not to be hit during the generation of these types. Instead I introduced a new concept of unambigious types as part of let statements and filtered out cases that the issue seemed to be pointing at.

    There were two tests that seemed to depend on the old behavior that I cleaned up in order to bring into alignment with the new behavior, this

    This should solve #10446

    opened by emeryc 2
  • Many macros incorrectly get the

    Many macros incorrectly get the "operation requires unsafe block" error

    Lately I've seen it doing this when using these macros:

    • println!
    • assert_eq!
    • proptest! (not part of std, but still has this issue)
    • write!
    • env!
    • eprintln!
    • format!

    This does not happen on nightly, but it does happen on rust 2021 and rust 2018.

    Example code (note that this compiles just fine):


    fn main() {
            "example text here {} {}",


    name = "example bug"
    version = "0.1.0"
    edition = "2021"
    description = "Example bug."
    license = "MIT"
    publish = false

    Rust-analyzer version: rust-analyzer d616a6a45 2021-06-06 nightly

    I at first thought that this was another instance of #5996, but it doesn't seem to be.

    PS: For some reason I don't have permission to comment unless I am closing the issue.

    opened by Lazerbeak12345 3
Building next-generation IDE tooling for Rust
Rust language support in Atom - LOOKING FOR MAINTAINER, see #144

Rust language support in Atom Adds syntax highlighting and snippets to Rust files in Atom. Install Install the package language-rust in Atom (Preferen

Andreas Neuhaus 118 Nov 8, 2021
RustDT is an Eclipse based IDE for the Rust programming language:

Project website: As of 2017, RustDT is no longer actively maintained, see this blog post for more information. If you are int

null 352 Aug 22, 2021
The official Sublime Text 3 package for the Rust Programming Language

Rust Enhanced About This is a Sublime Text 3 package which supports Rust starting with version 1.0, it makes no attempt at supporting earlier incompat

The Rust Programming Language 651 Nov 18, 2021
Kakoune Language Server Protocol Client

Kakoune Language Server Protocol Client kak-lsp is a Language Server Protocol client for Kakoune implemented in Rust. Installation Note kak-lsp.toml d

null 419 Nov 25, 2021
Language Server Protocol (LSP) support for vim and neovim.

For legacy python implementation, see branch master. LanguageClient-neovim Language Server Protocol support for vim and neovim. More recordings at Upd

Junfeng Li 3.3k Nov 21, 2021
An experimental proofreading and linting language server for markdown files ✍️

prosemd is an experimental proofreading and linting language server for markdown files. It aims to provide helpful and smart diagnostics when writing

Phil Pluckthun 55 Nov 23, 2021
Eclipse Corrosion - Rust edition in Eclipse IDE

Eclipse Corrosion Rust edition and debug in Eclipse IDE Corrosion is a Rust development plugin for the Eclipse IDE, providing a rich edition experienc

Eclipse Foundation 166 Nov 18, 2021
Emacs configuration for Rust

Table of Contents Introduction Installation Melpa Manual installation Feature guide Indentation Code formatting Running / testing / compiling code Cli

The Rust Programming Language 767 Nov 29, 2021
Rust development environment for Emacs

Rustic Table of Contents Rustic Intro Installation straight Compilation Faces rustc errors Rustfmt edition 2018 LSP Server Client eglot lsp-mode lsp-e

null 449 Nov 27, 2021
Better Rust/Cargo support for Flycheck

flycheck-rust — Flycheck for Rust This Flycheck extension configures Flycheck automatically for the current Cargo project. Setup Install from MELPA or

Flycheck 105 Sep 4, 2021
NetBeans Rust plugin

Rust NetBeans Plugin A NetBeans plugin for Rust. Linux / OSX Windows Requirements NetBeans 8.2.x Java 8+ Rust Cargo Rustup Features So far, it include

drrb 47 Mar 28, 2021
Rust plugin for the IntelliJ Platform

Rust plugin for the IntelliJ Platform Build Status Check Stable Beta Nightly Installation & Usage Available installation options and features are desc

IntelliJ Rust 3.8k Nov 25, 2021
Rust IDE

This branch contains the development of a "new ride" that maintain a small impact on the ui library. This is for a few reasons. Can customize the colo

Gustav Jansson 169 Nov 5, 2021
An IDE for Rust

Introduction SolidOak is a simple IDE for Rust. See the website for binary releases. It has the following features: An embedded copy of Neovim as its

Zach Oakes 903 Nov 18, 2021
Vim configuration for Rust.

rust.vim Description This is a Vim plugin that provides Rust file detection, syntax highlighting, formatting, Syntastic integration, and more. It requ

The Rust Programming Language 2.9k Nov 21, 2021
Rust Cargo command bindings

Vim Cargo Simple vim command bindings to quickly run cargo stuff from vim. Commands Available, mapping with their Cargo equivalant: CargoBench CargoBu

Timon Vonk 41 Jul 22, 2021
Visual Studio extension for Rust

Visual Studio extension for Rust Currently in development, and not feature complete. Stable versions are available on the Visual Studio extension gall

PistonDevelopers 686 Nov 23, 2021
Rust extension for Visual Studio 2017 with RLS support

Rust support for Visual Studio 2017 Preview Adds language support for Rust to Visual Studio 2017. Supports: code completion goto definition find all r

Zoey Riordan 108 Nov 18, 2021
crates is an extension aims to help people to manage their dependencies for rust ( & TOML).

crates Hello Rust & VSCode lovers, This is crates, an extension for dependencies. Aims helping developers to manage dependencies while using

Seray Uzgur 128 Nov 10, 2021