rls
rls copied to clipboard
rust-lang
Compiler backed code completion
Can do non-dot completion using a map of scopes to idents. Completion after the dot is harder, but we may be able to pre-compute lists of idents and try to stay ahead of the programmer as they type.
@jonathandturner is keen to do this sooner rather than later, so I'll write out in more detail what this entails and the open questions.
There are 2.5 kinds of code completion: completion after a dot (e.g., complete foo. or foo.ba), completion without a dot (e.g, foo( or on a newline), and completion of a path, i.e., after ::, this is the half case since it basically comes down to a simpler version of the dot case. I'll not cover it for the rest of this since all the issues apply to either the dot or non-dot cases.
The two kinds of completion need very different support from the compiler. Dot completion needs type information, specifically, it needs to 'see through' the various adjustments the compiler does at ., then get a list of fields (pretty easy) and a list of methods (harder, requires knowledge of the trait system. The unknown for me here is that currently the compiler answers the question "is there an implementation of a method with a specific name for a specific type" where we want an answer to "what are all the names of methods with any implementation for a specific type" (where "specific" is not that specific because of adjustments at the dot). @nikomatsakis, do you know what is required in the compiler to do that?).
For non-dot completion we need name resolution information, this is generally easier to do than type-related stuff. Given a position in the program we need a list of all names currently in scope. Again, the difference from regular compiler runs is that we usually ask "is this specific name in scope" rather than ask for all names. @jseyfried, do you know how big of a change that would be?
The other axis is whether the RLS computes completion info ahead of time or on demand. On demand means we wait for the user to press ctrl + space, then start a build asking for completion info. This might work when the compiler gets very incremental, but for now (and the near future) this is way too slow (for large crates). We can go a bit faster by doing this when we have a . in the code that is not followed by anything, but that probably doesn't help too much. I believe @jonathandturner is interested in knowing how slow this is, especially for small crates and this would be nice to know.
Alternatively, we can try and compute data ahead of time. This seems easier for non-dot completion. We can probably guess a function body to compute for pretty easily (last one edited or hovered, say). Then when we build (or we can start a build) we ask for completion info for every scope in the function, code completion should then be very fast. Since name resolution is pretty fast, I believe this should not impact compile times too much. In fact, we might even do it for a whole file (or module) rather than a single function. We should experiment to find out the time costs. I believe that for non-dot completion this is a strategy that can be implemented today and doesn't have any blockers, just needs the implementation work in the compiler and RLS (which is not to say that it is trivial).
I wonder whether we can compute dot completion info ahead of time. We could presumably find every location in the code (again, probably within a specific function body) where a dot could be added and get info that location as if there were a dot. This seems like it is adding a few new concepts, plus trait resolution is slow (c.f., name resolution) so this might be too expensive in practice, I'm not sure. It would be good to get input from the compiler team on this (cc @eddyb @arielb1).
You can get the expression types ahead of time and enough information on fields, methods to query dynamically outside of the compiler - should be faster in the compiler though, especially as we cache more and more - in fact, @nikomatsakis' plan for revamping trait lookup would make it impossible to beat. But I should let him tell you how we might end up with a type-walking bytecode :grin:
@nrc
I'm quite sure you can do dot completion using the type-context you get after compilation - it already has the type information for all nodes.
@nrc
The unknown for me here is that currently the compiler answers the question "is there an implementation of a method with a specific name for a specific type" where we want an answer to "what are all the names of methods with any implementation for a specific type" (where "specific" is not that specific because of adjustments at the dot). @nikomatsakis, do you know what is required in the compiler to do that?).
We actually have something very similar to this already. As part of the PR that added suggestions ("maybe try as_slice()"), there is a mode in method lookup that will find a list of all methods whose return type is compatible. It'd be a small thing to generalize that to "all methods you could call" and then filter that result with "whose return types are compatible". In fact, that was sort of my plan all long.
That said, I agree with @eddyb that in the more medium term I want to be doing this using the new trait system implementation. Specifically I wanted to move method lookup queries into that system. @aturon and I are hoping to start implementing this approach sooner rather than later (i.e., Q1 time frame), so this may be not that far off, though we've not made concrete plans.
Taking this off the beta milestone, would be good to have, but this shouldn't block IMO, and I don't think compiler support will be mature enough in the beta timeframe
@nrc
@jseyfried, do you know how big of a change [getting all names in a scope] would be?
This would be very straightforward to implement for not type-related stuff. We already can walk through all items in a lexical scope to collect potential extension traits for a method call, so this is mostly implemented.
Are there any news about this issue? Autocompletion on VSCode (which should use RLS) is not great.
Compiler support for a full solution is looking further and further off :-( Currently I wouldn't expect that to happen until early 2019, and being able to reliably use that in the RLS might take longer. It's possible we might be able to work on an intermediate solution later this year, but for now we're concentrating on getting a 1.0 release with Racer support.
Ok, thanks! :-)
On Wed, Mar 21, 2018 at 9:04 PM, Nick Cameron [email protected] wrote:
Compiler support for a full solution is looking further and further off :-( Currently I wouldn't expect that to happen until early 2019, and being able to reliably use that in the RLS might take longer. It's possible we might be able to work on an intermediate solution later this year, but for now we're concentrating on getting a 1.0 release with Racer support.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rust-lang-nursery/rls/issues/6#issuecomment-375172949, or mute the thread https://github.com/notifications/unsubscribe-auth/AFwP63HcGGME6oWm4WefLM2uyHTkQYDIks5tgyLAgaJpZM4KKUI5 .
-- - Giulio
Hello there from the future! Is there any progress on the issue? RLS is awesome and super useful, however, I think that lots of people are waiting for the sane and full editor completions, which will substantially help in learning the language. What about the intermediate solution you were talking about? Is there a way we can help? Maybe write some kind of PoC for the compiler-driven completions?
https://github.com/rust-lang-nursery/rls/issues/6#issuecomment-375172949 is still about right. There has been no progress, but its still a highly desired feature.
@nrc, to be honest, I think that "highly desired feature" is a very big underestimation. It might be an unpopular opinion, but for me personally the current development experience is not enough to jump on the rust train. Coming from .NET ecosystem, you learn to treat your intellisense as the main source of documentation and info, and therefore it makes it too frustrating to be finding yourself opening documentation over and over again.
Nevertheless, I love the language, the ecosystem and the community around it and wish a lot, that one day, rust will be able to compete with tools like Resharper in the level of developer comfort.
Also, is there any possible temporary solution to the problem or any way we can help?
or any way we can help?
I could give some context: during early 2018, there was talk of a huge refactoring of the compiler to make it much easier for RLS¹ to talk to the compiler constantly, invalidating the input as it changes, and asking for various bits of information (e.g. possible completions).
However, that sort of thing requires coordinating large-scale changes, and the focus for the past year was mostly on the 2018 editions, including NLL (which is on by default in Rust 2018). As we stand, such coordination would require full-time involvement of compiler developers in either the actual development, or at the very least mentoring and review.
If you work full-time on Rust, you typically have to do so as directed by the organization employing you for your full-time involvement in the project, with various goals in their mind. So if we want this to happen, Mozilla and others would need to make it a goal, and sponsor it.
(There are some mentions of a Rust Foundation here and there, and the advantages and drawbacks of such an organization, but it doesn't exist today so we can't do anything through it)
¹it's possible today, but incremental doesn't yet e.g. skip large chunks of parsing, and you can't directly limit how much you recompute, or in what order (e.g. completions before checking for errors)
Since this issue is finally gaining some traction, is there a way we can make our voice to be heard?
@eddyb, thanks for such a detailed answer! I can agree with @peperunas, that we have to do something (if it is even possible), for our voices to be heard. Maybe it would have been nice to make a couple of polls on official rustland twitter, etc?
For example: "I am a rust developer, I would like those changes to be prioritized", "I am a rust developer, I don't consider this issue important", "I want to start using rust, but absence of good tooling doesn't allow me", "I am learning rust and I am ok without good intellisense". Something like this.
Because maybe it is just me and a couple of very needy developers who are not satisfied and the others who came from C++ and C backgrounds are totally ok with that. It would be nice to know, or even gather people around the issue.
@peperunas @skyne98 I have no idea what would actually happen, but I'd suggest trying to figure out who you're trying to appeal to. Rust teams? Mozilla? Other organizations?
Because if it's the Rust teams themselves, I believe what I said still applies.
@skyne98 Couple things:
-
The main way we have for such global feedback is the survey and roadmap processes. The 2018 survey results should be posted soon, and the roadmap process will kick of some time in December.
-
FWIW, pretty much everyone involved is very aware of how important this feature is for many people. The problem is that, as @eddyb said, implementing it will require a big compiler effort (which we do plan to do). For Rusty 2018, the goal has primarily been to have a robust, "basic" IDE experience as a first step, which the RLS has essentially reached.
@eddyb, I think that better compiler infrastructure should benefit everyone. Rewriting it might spawn a lot of useful analytics tools, that will interest companies a lot, considering, for example, better automatic code reviews, as well as the possibility for new programmer to more easily integrate into their workflows, using smart intellisense with documentation.
@aturon, I am very glad to hear, that there is a chance of it becoming a reality in 2019. I think lots of people will be waiting for the results with their fingers crossed.
@skyne98 I agree, but you would have to get those companies to sponsor that development of compiler infrastructure, otherwise it will move slowly for another year if there are other things to do.
@skyne98
I am very glad to hear, that there is a chance of it becoming a reality in 2019.
To clarify: I'm not trying to make any predictions about the timing of these improvements. That should become more clear in ~February, when the compiler team will fully work out its plan for the next Edition (Rust 2021) and for 2019 specifically.
One more motivation for this ticket could be taken from the results of the Rust survey, which stays:
Looking closer at these users who feel unproductive in Rust, only about 25% are in their first month of use. The challenge here is to find ways to help bridge users to productivity so they don’t get stuck.
Lack of reasonable intellisense (expected by majority of software engineers now days) for Rust is one of the reasons for the above. As for me, feeling of low productivity (when happened) is 90% attributed to lack of fast and decent intellisense. I hope, people, who are deriving actions from the survey results will make a connection to this and similar tickets.
Fast (let's say at the level of Typescript compiler) and decent (let's say at the level of Intelij for Java/Scala or even for Rust) intellisense will make Rust unbeatable in feeling of the high productivity.
And more from the survery:
The IDE support tools Rust Language Server and racer had positive support but unfortunately, of the tools surveyed, generated a few more dislike votes and comments.
Again, as for me, the cause is this and similar tickets related to lack of decent intellisense. I tried RLS and racer, and disliked the quality of the outcome, switched to Intelij Rust, which has got far better intellisense and in-flight code compilation support for Rust, but it is extremely slow.
This is something that the team is very aware of and we'd love to support that. We plan to discuss the possible approach to easily interact with the compiler to get the information, at the beginning of the next year.
@Xanewok FWIW, that discussion already happened at the Rust All Hands 2018, Berlin, at the start of this year, the work (on the rustc side) just wasn't funded. At the risk of repeating myself, people should keep that in mind as it can be a major factor in whether planned things happen or not.
@eddyb, I think that this issue has already been discussed here and that is the reason why we were expecting results of 2019's survey. It should give the team some motivation to include good IDE support into the 2019 rust roadmap.
@skyne98 I might be getting misunderstood: that's not that useful unless not much else happens all year, and even then it's no guarantee anything will happen at all.
We had a plan to tackle this for 2018 but nothing happened.
This in part because the number of people working full-time on the Rust compiler is incredibly small for how many users Rust has.
The roadmap doesn't come with guaranteed assignments of resources - maybe it should, but currently it doesn't and I doubt Mozilla can tackle everything Rust should be doing, alone.
@eddyb, I see, thanks for the insight! Anyways, I hope that the higher-ups will find the development experience issue important enough to consider spending time and resources on it. In my opinion, and it seems like it aligns well with opinions of many people, it will have rust gain even more popularity, which it truly deserves.
As a fledgling rustacean I would like to put my support behind this as well. I come from a Java and C# background and use C# for work. I learned C# almost exclusively through my understanding of Java and intellisense in Visual Studio. I understand I probably shouldn't be so dependent on my IDE's, but it's how I've been learning at this point. If the Rust intellisense could become more complete it would be a real help for me to pitch using it both myself and to my team at work.
I love the language and its features. Honestly I think it's the first language of its kind and it definitely fills a gap in what languages can do. The only thing it's missing for me at this point is the "comfy" development features that make it easier for me to learn what I'm doing.
That said, the existing documentation building is FANTASTIC (rustup doc etc.) so I suppose I can patiently wait while it comes out. I'm just wondering on the status of RLS and what I can be getting excited for in the coming year. 😄
@TimVanDyke you might want to give rust-analyzer (Code marketplace) a try. There are some trade-offs, but you might find that its code completion works well enough for you.
racer(current RLS completion backend) has some fundamental issues that are hard to fix. rust-analyzer is intended to overcome such difficulties (like macro completion) and has a more compiler-like structure, though it's still not compiler-backed.
bump! I'd really love to see this feature. Hate to nag, just wanted to let my voice be heard.
