Disable inlay type hints by default or at least for when skipping rustfmt?

[huntc]

Would it be reasonable to see the inlay type hints disabled by default? I find that the same information is provided when hovering over a variable.

Also, for my particular use-case, I use #[rustfmt::skip] for some code sections and the inlay type hints destroy the desired formatting. If disabling by default is unpalatable, not having inlay type hints for where formatting has been disabled would be great.

EDIT: Here's an example of my code that (hopefully) benefits from block formatting:

#[rustfmt::skip]
pub fn command_handler(state: &State, command: Command) -> Effect {
    match (state, command) {
        (State::Idle { observations }, Command::GetObservations)                                         => handle_get_observations(observations),
        (State::Idle { observations }, Command::ProcessAccelerometer { time, ref samples, samples_len }) => handle_process_accelerometer(observations, time, &samples[0..samples_len]),
        (State::Idle { .. },           Command::SetInsideMovement { time })                              => handle_set_inside_movement(time),
        (State::Idle { .. },           Command::SetOutsideMovement { time })                             => handle_set_outside_movement(time),
        (State::Idle { .. },           Command::Timeout)                                                 => Effect::None,

This is what it looks like with inlay types enabled:

Thanks for any consideration.

Refs:

• https://rust-analyzer.github.io/manual.html#inlay-hints
• Optimize the user experience when line gets too long after inlay hints are inserted. #3138

[flodiebold]

In general, we want all features enabled by default, because otherwise you might never know they exist.

I don't know about disabling inlay hints because of a rustfmt annotation, that seems like it would be rather surprising as well 🤔

[huntc]

I don't know about disabling inlay hints because of a rustfmt annotation, that seems like it would be rather surprising as well

What was surprising was to see my careful formatting was compromised visually having just switched to Rust Analyzer.

Is there a way I can save this setting’s value against my project so that others who open it, and who use Rust Analyzer, won’t be surprised?

[flodiebold]

There are editor-specific ways to save settings local to the workspace, for example in VS Code.

(Edit: ... but I wouldn't actually recommend disabling IDE features in that; in my opinion that should be left to each user.)

[lnicola]

Speaking as an occasional contributor to other projects (as opposed to a rust-analyzer developer), I wouldn't be keen on losing IDE features for the sake of some #[rustfmt::skip] sections. Depending on your code, you might be able to format it a little differently (e.g. by inserting newlines) so that the hints don't make it look weird. And of course, local workspace settings (as above) should work for you.

For "novelty" code I'd recommend the viewer to disable hints if they want it to look right.

[huntc]

Thanks for the dialogue on this topic. I've edited the original description to include an example of the code I'm formatting, and a screenshot to show what happens with inlay type hints enabled. I'm certainly open to feedback on how others may go about formatting for my use-case.

[lnicola]

Yeah, that's fair code. For me, this would probably be "good enough":

#![allow(unused_variables)]
#![allow(dead_code)]

use std::cell::RefCell;
use std::rc::Rc;

pub struct CircularQueue<T> {
    values: Vec<T>,
}

pub enum Command {
    GetObservations,
    ProcessAccelerometer {
        time: u32,
        samples: [u32; 64],
        samples_len: usize,
    },
    SetInsideMovement {
        time: u32,
    },
    SetOutsideMovement {
        time: u32,
    },
    Timeout,
}

pub enum State {
    Idle {
        observations: Rc<RefCell<CircularQueue<u32>>>,
    },
}

pub enum Effect {
    None,
}

#[rustfmt::skip]
pub fn command_handler(state: &State, command: Command) -> Effect {
    match (state, command) {
        (State::Idle { observations }, Command::GetObservations)
            => handle_get_observations(observations),
        (State::Idle { observations }, Command::ProcessAccelerometer { time, ref samples, samples_len })
            => handle_process_accelerometer(observations, time, &samples[0..samples_len]),
        (State::Idle { .. }, Command::SetInsideMovement { time })
            => handle_set_inside_movement(time),
        (State::Idle { .. },Command::SetOutsideMovement { time })
            => handle_set_outside_movement(time),
        (State::Idle { .. }, Command::Timeout)
            => Effect::None,
    }
}

fn handle_get_observations(observations: &Rc<RefCell<CircularQueue<u32>>>) -> Effect {
    todo!()
}

fn handle_set_outside_movement(time: u32) -> Effect {
    todo!()
}

fn handle_set_inside_movement(time: u32) -> Effect {
    todo!()
}

fn handle_process_accelerometer(
    observations: &Rc<RefCell<CircularQueue<u32>>>,
    time: u32,
    samples_len: &[u32],
) -> Effect {
    todo!()
}

fn main() {}

but I have a very high threshold for disabling rustfmt.

In this case I'd probably split the match and move the handling of each State into a different function.

[Veykril]

This would probably make more sense to think about as a r-a specific tool attribute cc #7449