How to get rust-analyzer to "see" my extension methods

help
1

Anyone know how rust-analyzer decides what to show automatically even if a module isn't in scope e.g., "extension methods" from a trait not in scope that a type in scope implements? For example, I defined a Headers type in a module, and in the same module defined a HeadersExt that adds some helpful methods we don't always want in scope (not relevant for most use cases). These do show up automatically in VSCode's completion list a la rust-analyzer.

Meanwhile, I have a trait named ClientBuilder in another crate implemented a type (e.g. name) SubClientBuilder but if ClientBuilder isn't in scope, I don't see the implemented methods.

In both cases, the types are defined in a "core" crate with no prelude and I tried exporting both from the crate root to no avail.

In the HeadersExt case, rust-analyzer shows "ext_fn() (use core::HeadersExt)" and, sure enough, if I select it core::HeadersExt is added to the imports. That doesn't happen with the ClientBuilders trait's methods.

The only difference is that ClientBuilders has 1 method with no default implementation, and a few that do have default implementations. HeadersExt defines default implementations for all methods.

I would really like the same dev experience for ClientBuilders (which I also tried adding "Ext" to just in case it was a naming convention light-up). So how does rust-analyzer decide when to show "extension methods" and add imports as needed?

Some relevant code:

2

The other difference is that ClientBuilder is behind a feature. I don't remember if RA defaults to compiling with all features, but if not you can add it: rust-analyzer.cargo.features

1 Like
3

Good idea. I did already have that set to "all", though, in .vscode/settings.json. Still, maybe there's a corner case in there. I will try moving it out from behind a feature just in case that is an issue.

4

Alas, moving those features from out of a feature didn't help. Would this be better to as in rust-lang.zulip.org of the t-compiler/rust-analyzer team? I've used it for discussions about proposed features. This seemed more of a user question, but may require more in-depth knowledge if not point to a bug (probably not, but not impossible).

5

That's a good idea. It does seem like there's some things rust-analyzer forgets autocomplete for.

Most of these don't apply or would be obvious for other reasons, but here's all the things I know of that could make rust-analyzer ignore it on purpose:

  • The trait isn't public (both are sort of public and reexported)
  • The function is deprecated or doc(hidden)
  • You're inside of a macro
  • The rust-analyzer either doesn't know the type you're calling it on, or the type doesn't implement ClientBuilder
  • Something else in the project doesn't compile and is preventing rust-analyzer from knowing types
  • You're inside code that rust-analyzer is ignoring or isn't aware of

You can test these in various ways, and if you can implement HeadersExt and ClientBuilder for a single type, that would narrow it down considerably.

6

Thanks. I had checked those before posting, but it's great to confirm. HeadersExt and ClientBuilder are implemented for a single thing now. Or if you meant a minimal repro, normally I would but I'm wondering if there is more context as to why within the current source. I'll be sure to include those links above, though, and at least point to specific source.

1 Like
7

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.