Ability to rename generated context selectors via IDE tools like rust-analyzer

[clouds56]

I always feel frustrated when I'd like to refactor Error enum, since I could not use "Rename Symbol" feature provided by vscode and rust-analyzer.

When I add PackageBConfigError, I'd like to rename ConfigError to PackageAConfigError, but it would cause compilation failing since vscode would not rename ConfigSnafu to PackageAConfigSnafu for me.

#[derive(Debug, snafu::Snafu)]
pub enum Error {
  #[snafu(rename = "ConfigSnafu"] // <-- suggest adding optional rename field helps IDE to do refactor
  ConfigError { .. },
  PackageBConfigError { .. }
}

Is there any workaround?

My sugguestion

Shall we allow an attr that be the span of generated Snafu struct? We could do refactor maybe in this way.

1. add corresponding attr #[snafu(rename = "ConfigSnafu"] to ConfigError { .. },
2. press F2 on ConfigError to rename to PackageAConfigError, but it would still use ConfigSnafu for context
3. press F2 on ConfigSnafu to rename to PackageAConfigSnafu
4. delete temp attr #[snafu(rename = "PackageAConfigSnafu"]

[shepmaster]

Doing a quick check with some rust-analyzer developers, they seem to suggest that the explicit attribute path would work. It'd probably look more like this to match existing SNAFU style:

#[derive(Debug, snafu::Snafu)]
pub enum Error {
    #[snafu(context(name(ConfigSnafu)))]
    ConfigError { .. },
}

However, they also suggest that rust-analyzer could be enhanced to understand these kinds of prefix/suffix renames, so I'm chatting with them to understand what that might entail.

[shepmaster]

The rust-analyzer route is proving to be more difficult, so I took a crack at the explicit name option. If you have time, check out the branch and see if it does what you expect:

[dependencies.snafu]
git = "https://github.com/shepmaster/snafu"
branch = "name-selectors"

[clouds56]

It works like a charm! Exactly what I think!
Hope one day rust-analyzer would support this scenario.

[shepmaster]

Hope one day rust-analyzer would support this scenario.

rust-lang/rust-analyzer#19893 has been merged, which offers the most fundamental pieces of this:

That should eventually roll out through the normal rust-analyzer distribution paths, so I'll mark this issue as closed for now.

[clouds56]

Would it work for things like

GammaError, // rename to Gamma
Gamma, // rename to GammaError
GammaError, // rename to Alpha
GammaError, // rename to AlphaError
Gamma, // rename to AlphaError

[shepmaster]

If I’m understanding you correctly, no it would not cover those cases. Ultimately, the change that is in rust-analyzer is a very broadly applicable one; anything having knowledge about the word “error” or “snafu” would require very specific knowledge.

[shepmaster]

However, the rust-analyzer folk were open to some amount of "heuristics" that would be more general. That is, if some sort of common subset of the identifier being renamed could be discovered, then that could be an enhancement. So if we can think of something that would work for FooBarBaz producing a token like AlphaBarOmega and then renaming FooBarBaz to OneGreenTwo and detecting that we need to rename to AlphaGreenOmega (not a good example, I'm being handwavy here) then I think they'd at least be open to listening about it.