rust-lang / rust-lang/rust-analyzer

`rust-analyzer.completion.callable.snippets: "none"` is not always respected

Open
#19,175 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

C-bug
Dominant language
Rust
Stars
16.9k
Forks
2.2k
Avg merge
1d 12h
Merged PRs (30d)
72

Description

I tend to find the snippet completions of callables to be more trouble than they are worth, especially when it comes to initiating structs.
And so I want to turn them off.

Unfortunately the rust-analyzer.completion.callable.snippets config does not seem to apply to struct completions.

Since I haven't been able to find any other setting specifically for structs I can only assume that this is a bug.

rust-analyzer version: rust-analyzer 1.84.1 (e71f9a9 2025-01-27)

rustc version: rustc 1.84.1 (e71f9a9a9 2025-01-27)

editor or extension:

NVIM v0.10.4
Build type: RelWithDebInfo
LuaJIT 2.1.1736781742

relevant settings:

default_settings = {
  -- rust-analyzer language server configuration
  ['rust-analyzer'] = {
    completion = {
      postfix = {
        enable = false,
      },
      autoimport = {
        enable = false,
      },
      callable = {
        snippets = "none",
      },
    },
  },
}

code snippet to reproduce:


mod amod {
    #[derive(Debug)]
    pub struct AnInitializerStructuWithManyFields {
        pub a_long_field_name: u32,
        pub b_long_field_name: u32,
        pub c_long_field_name: u32,
        pub d_long_field_name: u32,
        pub e_long_field_name: u32,
        pub f_long_field_name: u32,
        pub g_long_field_name: u32,
        pub h_long_field_name: u32,
        pub i_long_field_name: u32,
        pub j_long_field_name: u32,
        pub k_long_field_name: u32,
    }

    pub fn a_function_initialized_with_said_struct(init_args: &AnInitializerStructuWithManyFields) {
        println!("{init_args:?}");
    }
}

fn main() {
    // Start typing the following and let analyzer suggest completions:
    // amod::a_function_initialized_with_said_struct(&am

    // Expected completion behavior:
    amod::a_function_initialized_with_said_struct(&amod::AnInitializerStructuWithManyFields

    // Actual (incredibly unhelpful) behaviour:
    amod::a_function_initialized_with_said_struct(&amod::AnInitializerStructuWithManyFields { a_long_field_name: (), b_long_field_name: (), c_long_field_name: (), d_long_field_name: (), e_long_field_name: (), f_long_field_name: (), g_long_field_name: (), h_long_field_name: (), i_long_field_name: (), j_long_field_name: (), k_long_field_name: () }

    // If you continue to type until you complete the namespace before letting analyzer suggest completions:
    // Eg. `amod::a_function_initialized_with_said_struct(&amod::`
    // Then I am offered the expected completion of simply the plain struct name.
    // Which 9/10 is what you want if the structure has more than 3 fields since
    // then you can make use of init shorthands and defaults like below:

    let f_long_field_name = 42;
    amod::a_function_initialized_with_said_struct(&amod::AnInitializerStructuWithManyFields {
        f_long_field_name,
        ..Default::default()
    });
}

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running the provided Rust reproduction with rust-analyzer and the shown callable.snippets setting. Trace completion handling for struct initializers and how that setting is applied; done means struct completions no longer expand into field-initialization snippets when the setting is "none".

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.