Support doc(alias)-based completion

[hecatia-elegua]

To put it simply, I have some funny named registers like PORTPMSC but want to give them real names, in this case something like PortPowerManagementStatusControl (not exactly, but you get the idea).

doc(alias("PORTPMSC"))
struct PortPowerManagementStatusControl { ... }

Sometimes the name of the thing and its abbreviation in a specification is completely different though, so code completion will only work with the name in code, but I would like people to be able to use the spec abbreviations as well.

To get to the point: Where would I need to start looking to implement this? I.e. where in this repo is the code-completion handled and where the attribute parsing or generally attribute info?

[hecatia-elegua]

https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-completion/src/completions/type.rs I assume somewhere in here for the code completion aspect?

[Veykril]

That sounds great to have, not 100% sure how to add this though.
So I think what we probably want to do the following:

rust-analyzer/crates/ide-completion/src/context.rs

Lines 494 to 504 in 82ec458

	/// A version of [`SemanticsScope::process_all_names`] that filters out `#[doc(hidden)]` items.
	pub(crate) fn process_all_names(&self, f: &mut dyn FnMut(Name, ScopeDef)) {
	let _p = profile::span("CompletionContext::process_all_names");
	self.scope.process_all_names(&mut |name, def| {
	if self.is_scope_def_hidden(def) {
	return;
	}
	f(name, def);
	});
	}

Here we want to check for aliases of the def, and if we find any invoke the callback with the aliases as well. You should be able to figure out how to handle the attribute part by checking how that function already handles the doc(hidden) stuff, but if you run into problems there feel free to ask

[hecatia-elegua]

I'm about halfway there, but turning the alias into a Name sounds wrong, see:

rust-analyzer/crates/hir-expand/src/name.rs

Lines 66 to 71 in 82ec458

	/// Note: this is private to make creating name from random string hard.
	/// Hopefully, this should allow us to integrate hygiene cleaner in the
	/// future, and to switch to interned representation of names.
	const fn new_text(text: SmolStr) -> Name {
	Name(Repr::Text(text))
	}

[Veykril]

Hm, right the alias is a string here, not an ident. Let's just cheat here like we are already in collector here to create an arbitrary name,

rust-analyzer/crates/hir-def/src/nameres/collector.rs

Lines 90 to 93 in 82ec458

	// FIXME: a hacky way to create a Name from string.
	let name =
	tt::Ident { text: it.name.clone(), span: tt::TokenId::unspecified() };
	(name.as_name(), ProcMacroExpander::new(base_db::ProcMacroId(idx as u32)))

(and put an appropriate FIXME on that as well)

[hecatia-elegua]

Apparently I don't understand how to debug this with just printing or the trace crate at all, will get back to this tomorrow.
Maybe I should put tests somewhere first and try with those like it says in the dev docs

[Veykril]

writing a test and then print debugging that test is usually easier (and faster)

[hecatia-elegua]

just updating: completion is suggesting the alias now, but it doesn't complete into the actual name, but the alias.
two ways we could get around this:

• PORTP$0 shows PortPowerMa... as completion only (which would be better than nothing)
• PORTP$0 shows PortPowerMa... and PORTPMSC, but clicking PORTPMSC resolves to PortPowerMa... (do we have any precedent for completing to something different than displayed? or would it be possible to kinda display PORTPMSC -> PortPowerMa..., maybe like function types get displayed? That would be awesome.)

[Veykril]

Right, the name used is what will be inserted ... I don't think there is currently any precedent to simple name completions completing to a different name than listed.

The -> idea isn't too great, I think that might be confusing to some people and it might also clutter, we could do something similar to what we do with trait items though,

here we do cmp (as Ord), so maybe something like PortPowerMa... (alias PORTPMSC)?

[hecatia-elegua]

Just surfing through CompletionItem code, which has TextEdit, though that's used for item_lists and such.
I think having the real completion is better here.
I'll do your idea, which is great, didn't think of that :)
It is handled here, similar to use as well:

rust-analyzer/crates/ide-completion/src/item.rs

Lines 419 to 427 in a375ad6

	if let [import_edit] = &*self.imports_to_add {
	// snippets can have multiple imports, but normal completions only have up to one
	if let Some(original_path) = import_edit.original_path.as_ref() {
	lookup = lookup.or_else(|| Some(label.clone()));
	label = SmolStr::from(format!("{label} (use {original_path})"));
	}
	} else if let Some(trait_name) = self.trait_name {
	label = SmolStr::from(format!("{label} (as {trait_name})"));
	}

[hecatia-elegua]

Ok, I'm nearly there, but I need ScopeDef or some other way to get the attribute information.
If I understand correctly, I should not be calling my stuff in process_all_names anymore, but somewhere else, probably src/render/literal/fn render, which funnels it to src/item/Builder.build. ModuleDef can get attrs as well.
Any pointers?

[Veykril]

Only ModuleDefs can have relevant attributes here (which ScopeDef delegates to). I'm not quite sure how to handle this right now, but we do still want to do something in process_all_names since we do want to show completions for both the normal name but also for the alias. So we somehow need tosignal completions called in process_all_names that the name we pass is an alias and not the name that is actually in scope right now, so that the logic can render the completion lookup with the alias but not insert the alias.

[hecatia-elegua]

Ugh, so all callsites of process_all_names need to handle this? I hoped this would not be the case... well, I'll try to hack it together for now. Thanks

[Veykril]

Unfortunately yes, I am not happy with how that currently works either. But I can't really think of a better way to do that right now.