Hello, I'm a rust-analyzer maintainer and we consider removing term search. For that we'd like to know if people are using it.
I think I know what term search is, but I never used it in rust, and I didn't know rust-analyzer supports it either.
since I never used it, I don't know how well it performs. personally, I'm ok with rust-analyzer removing it, assuming it's a niche feature but adds significant maintanence burden. but it's just me, I don't know how the community think.
also, I think even if someone uses it, these days LLM based code assistant usually does the job equally well (or better, arguably?).
p.s.
I learned the concept when I tried idris long ago (but never delved deeply into), where I also learned the phrase "type driven development" and what a typed "hole" is.
unlike idris, where the editor integration feature[1] is built into the type checker itself, the rust language server is a separate tool, outside the compiler. besides, idris is dependently typed. unless we can adapt the real rustc type checker for code editing, I don't think it worth it for rust-analyzer to support a rarely used feature which requires deep knowlege of the type system.
it's idris specific: it was before LSP was a thing, or at least before it was popular anyway âŠī¸
i assume term search only means expression hole filling and not "figure out the correct return type for fn foo() -> _ { .. }", in which case i don't use it, and i didn't know it existed.
We've come into conclusion to not remove it as of now, we're only removing its integration with borrow checking (since we remove borrow checking).
"Figure the return type from the body" is available and not considered for removal.
Given the results of the poll, are you going to actually tell us what "term search" is?
Looks like: Given a known target type, come up with a list of expressions resulting in that type which use the variables etc. available at the given code location. (Challenging part getting ripped out AAUI: limiting suggestions to those that pass borrow check.)
Example from the original PR:
pub fn name(self, db: &dyn HirDatabase) -> Name {
// At this error location it suggests one of
// ```
// self.name(db)
// GenericParam::TypeParam(self).name(db)
// self.merge().name(db)
// ```
// etc
}
Comment from the original PR:
/// Internally this function uses Breadth First Search to find path to `goal` type.
/// The general idea is following:
/// 1. Populate lookup (frontier for BFS) from values (local variables, statics, constants, etc)
/// as well as from well knows values (such as `true/false` and `()`)
/// 2. Iteratively expand the frontier (or contents of the lookup) by trying different type
/// transformation tactics. For example functions take as from set of types (arguments) to
/// type (return type). Other transformations include methods on type, type constructors and
/// projections to struct fields (field access).
/// 3. Once we manage to find path to type we are interested in we continue for single round to
/// if we can find more paths that take us to the `goal` type.
/// 4. Return all the paths (type trees) that take us to the `goal` type.
///
/// Note that there are usually more ways we can get to the `goal` type but some are discarded
/// reduce the memory consumption. It is also unlikely anyone is willing ti browse through
/// thousands of possible responses so we currently take first 10 from every tactic.
Yes, that is correct.
Sorry for the tangent, but I'm wondering if there is a feature like "fill with inferred type" (in type expression position). And if there is, how to use it? Because I had a few situations where I really wanted such a thing and couldn't find it.
I'm not sure what you want. There is an assist to insert an explicit type for a variable. We don't have an assist to replace _ with the actual type (aside from in function return type), but we do have the infrastructure for that in place so we can do that (we show the type on hover and in inlay hints, if you have that configured).
that actually seems very interesting, i should probably enable it to try it out.
i think the main issue with the feature is discoverability, it's disabled by default and if I'm not told it exists i would never realise that it exists,
maybe a assist (which always goes last in the assist list) for cases where the feature would do something, but is disabled, that just says "term search is disabled, use me to temporarily enable it, or edit your config to permanently enable it" could help
does it only work for function bodies or can i also use it in arbitrary contexts (e.g. completing the scrutinee of a match, or a specific function argument)?
Match scrutinees and function arguments are inside bodies?...
But anyway, why won't you try and see?
We have a very big feature discoverability problem. And we don't know what to do about it.
If you have not read the book cover-to-cover and regularly following the changelog, you're most likely missing some functionality in rust-analyzer.
yeah, discoverability is a big problem for a tool as a language server: users don't directly interact with the server, instead, they use whatever LSP client they chose.
and in fact even the client is somewhat hidden from the users, what the users actually perceive are some UI in their editors.
some of my personal ideas to improve the discoverability:
for vscode, we have control of the client plugin, so that could be a place where we can remind the user to explore and configure features they might not know, e.g. when the plugin (each new version?) is installed and activated for the first time, we can show a notification with a link to the config file or online documentation.
but for other editors, their lsp client integrations are not maintained by rust-analyzer, we need other methods. one potential place is code actions, since these are manually triggered by the user, as opposed to the usually automatically triggered code suggestions.
say, we can append an entry to the list of actions with something like: "Configure more rust-analyzer features". but this should be done very sparingly, e.g. only when the user has not created a custom config file (i.e. everything is in the default configuration) and only show this once per session.
I don't know enough about LSP, can this be implemented from the server side? specifically, can the server push the path of a config file for the client to open and edit? better yet, pre-filled with documented template content? or at least, push a url for the user to click? the config file can be versioned, so we can notifiy the user when there are new features available.