Rename type import to alias

[fritzrehde]

If I have use Type; imported, I would like to be able to refactor that to use Type as CustomName; (in VS Code). Then, I would like all instances that previously used Type in that file to now use CustomName.
Is this already possible in VS Code somehow?

[Young-Flash]

Maybe could impl within a assist

[fritzrehde]

Sorry, I'm not sure what your response means @Young-Flash. Do you mean the feature exists already and I could implement/use it by using this assist somehow? Or do you mean that rust-analyzer could implement this internally with assist?

[fritzrehde]

If it really doesn't exist yet, I would propose one could just use the normal rename LSP command (e.g. Fn+F2 on Linux) for this, which currently says "Cannot rename a non-local definition".

[alibektas]

👋

We have the infra for this so it should be easy to do. Do you want to do it @Young-Flash or should I do it?

[fritzrehde]

Awesome, great news!

[Young-Flash]

Do you mean the feature exists already and I could implement/use it by using this assist somehow? Or do you mean that rust-analyzer could implement this internally with assist?

@fritzrehde Sorry for the unclearness, it's the latter. That feature hasn't implement for now. assist for R-A is something that offer by a💡in VSCode, which implement here, you can learn more about it from this blog.

[Young-Flash]

We have the infra for this so it should be easy to do. Do you want to do it @Young-Flash or should I do it?

@alibektas I could have a try.

It's okay if @fritzrehde feel like to implement this personally, I think R-A Community will happy to help new contributor to make their first contribution, there are some related PR which could refers to

[alibektas]

We have the infra for this so it should be easy to do. Do you want to do it @Young-Flash or should I do it?

@alibektas I could have a try.

It's okay if @fritzrehde feel like to implement this personally, I think R-A Community will happy to help new contributor to make their first contribution, there are some related PR which could refers to

Sure I will be posting some instructions in a couple of hours that will help with the implementation.

[alibektas]

IMPORTANT : Implementing this as an assist has a serious shortcoming, so it'd be better if we'd implemented it as a special case of renaming. See comments below where the problem is discussed.

So let's talk about how this issue can be solved. I will mostly omit the assist-related part. For this you will have numerous examples in the ide-assists crate. Just take a look at one of the files and do shamelessly copy and paste. 😄

Renaming in rust-analyzer is handled by two crates : ide and ide-db. ide will be the endpoint for renaming, basically the thing that is called once we get a renaming request ( and btw the cannot rename non-local definition is a bug and is discussed here #15656 , it will soon be fixed ). What we will be using is the ide_db::rename::Definition::rename fn. The problem however is that this returns a SourceChange

rust-analyzer/crates/ide-db/src/source_change.rs

Lines 19 to 23 in c1c9e10

	pub struct SourceChange {
	pub source_file_edits: IntMap<FileId, (TextEdit, Option<SnippetEdit>)>,
	pub file_system_edits: Vec<FileSystemEdit>,
	pub is_snippet: bool,
	}

Two things immediately draw our attention about SourceChange :

1. We only want to edit a single file ( FileId is the unique Id that you need to be using ) so you will need to limit your findings to the scope of this file. This should give you an idea.
   

   rust-analyzer/crates/ide-db/src/search.rs

   Lines 315 to 324 in c1c9e10

   	pub fn usages<'a>(self, sema: &'a Semantics<'_, RootDatabase>) -> FindUsages<'a> {
   	FindUsages {
   	def: self,
   	assoc_item_container: self.as_assoc_item(sema.db).map(|a| a.container(sema.db)),
   	sema,
   	scope: None,
   	include_self_kw_refs: None,
   	search_self_mod: false,
   	}
   	}

2. Most of the assist ( probably all of them ) you will see build their own SourceChanges by using a SourceChangeBuilder but you can change a SourceChangeBuilder's SourceChange by accessing its .source_change field.

Feel free to ask any questions you have!

[Veykril]

I actually had the idea in my mind that trigger a rename on an import should introduce an alias as the initial issue here outlines as well. Though we could probably have both, that rename behavior and an assist (for discoverability).

[UserIsntAvailable]

👋 I'm interested in implementing this, however I some questions regarding how it will work for end-users (specially after reading #15656).

The way that I particularly would like to implement this would be: if Type is considered "Local" (by R-A terms) then perform the renaming as usual, otherwise create a type alias. So:

use std::io::Result;

fn main() -> Result<()> {
    Ok(())
}

then If I try to rename Result to IoResult, it would do this:

use std::io::Result as IoResult;

fn main() -> IoResult<()> {
    Ok(())
}

This would work fine, but some users might not want this behavior. I think we could use rust-analyzer.rename.allowExternalItems here (or change the name to something like rust-analyzer.rename.externalItems), then provide an enum with two options: 1) alias, would create an alias like I explained above, and 2) rename, would just rename it like the option does when it is true.

cc @alibektas, because you were the one that implemented rust-analyzer.rename.allowExternalItems; do you think this is a good idea?

---

As a side note, I don't have a problem having an assist (code action) to do this, we could provide both options like @Veykril proposed above.

[alibektas]

👋 I know the day would soon come where I would say to myself, I'd better made that bool an enum, I just wasn't expecting it to happen to soon 😄. But jokes aside I think we should avoid changing the said config. I don't think that we should be using type aliasing as if it were a fallback for renaming. I think it's justified to have a "special" renaming function around import statements. So what I am trying to say is that renaming on an import should always produce type aliases and I am not too sure about what I am going to say now but I don't think that there is a party that wouldn't welcome this.

Why don't you implement this feature first only as an assist but instead of having the actual function that does the heavy work implemented in ide-assist crate have it somewhere in ide-db ( probably ide-db::rename idk)?

[UserIsntAvailable]

@alibektas

I know the day would soon come where I would say to myself, I'd better made that bool an enum, I just wasn't expecting it to happen to soon

I imagine that you would have that reaction when I realized that the feature was implemented 2 weaks ago 🤣

Why don't you implement this feature first only as an assist but instead of having the actual function that does the heavy work implemented in ide-assist crate have it somewhere in ide-db ( probably ide-db::rename idk)?

Ok sounds good, however I have a pretty big question:

ide-assist handlers can only use "predefined" values, as in, users can not pass values to it? (It doesn't seem that AssistContext has nothing related with that) So if I implement this, the assist is just gonna create a "dummy" type alias for you?

like:

use std::io::Result; // <- assist "generate_type_alias"

fn main() -> Result<()> {
    Ok(())
}

to

use std::io::Result as TypeAlias;

fn main() -> TypeAlias<()> {
    Ok(())
}

If the answer is no (you can provide values), how is this done? I checked similar, assists and they seem to just hard-code the names.

If the answer is yes, then this is problematic, because renaming aliases is currently unsupported. As a side note, an code action for this wouldn't be necessary if you were able to rename aliases, because you could create an alias with the same name of the qualified type (e.g use std::io::Result as Result;) then rename the type alias to the name you want and it should work all the time?

---

Maybe I'm overthinking this too much? Another alternative that I see is:

// User wants to rename `Result` to `IoResult`.
use std::io::Result;

fn main() -> Result<()> {
    Ok(())
}

So they change it like so:

use std::io::Result as IoResult;

fn main() -> Result<()> {
    Ok(())
}

Then a supposedly (apply_alias?) gonna find all the usages then apply those changes automatically?