We’ve talked for a while about having better IDE support for Rust. It is a feature that has been much-requested from the community and from industrial users. There have been a few community projects that have done great work in the area (for example, Racer, RustDT). Over the next months, awesome IDE support for Rust is going to be a high priority for the Rust teams, and hopefully for the community.
I’d like to discuss the plans here, get some feedback, and find out how much interest there is for contributing.
The plan
Good IDE support requires a number of components - the compiler must be modified to operate in a different mode, we must provide name and type information from the compiler to the IDE, and we must write plugins for the IDEs themselves so they know what to do with Rust projects. We want to work on all three of these components in parallel. To discuss the technical details of the compiler, etc., there is an RFC PR.
The key parts of the RFC are:
- the compiler should be able to operate in a mode with incremental and lazy compilation,
- the compiler should handle incomplete code - i.e., it can recover to some extent from errors in parsing and name resolution,
- create an ‘oracle’ tool which takes data from the compiler, maintains a project-wide view of code and semantic information, and delivers data about the project to an IDE (or other tool) via an IPC API.
Rather than focus on a single IDE, we’d like to provide generic tools which will benefit all IDEs and be useful for developers who don’t want to use an IDE. However, there is a lot of work to be done on actual IDE integration, and having good theoretical support for IDEs without doing this integration work would be useless. Given existing community projects, we will focus on plugins for Visual Studio, Eclipse, and IntelliJ IDEA. By covering these three IDEs we will be able to offer a good IDE experience on all platforms. If there is strong community support for other platforms in the future we could make these projects official too, or offer other support. To some extent, Eclipse and IntelliJ IDEA overlap in the facilities offered and platforms supported. However, we think it is too early to pick one or the other, given that both are popular and have active projects with Rust. If one emerges as an obviously better choice, we could drop official support for the other.
Racer will continue as a stand-alone tool. In the short-term I expect it to remain the primary source of code completion information for editors (especially non- IDE editors). I imagine the oracle will learn a lot from Racer, and possibly share some code. In the long-term I expect Racer could make use of the oracle to provide faster and more accurate information.
To have a more permanent place to track development and to refer new contributors, there is a web page at [https://www.rust-lang.org/ides.html].
Ways to contribute
The easiest way to contribute is to use an IDE for your Rust development (if you’re not already). Hopefully this will have the pleasant side-effect of making you more productive! Let us know what your experience is like - what is good and what needs work. File issues on the appropriate repository (you can find links to the repos on the IDE webpage).
If you’re able to contribute code (or tests or documentation, etc.) either to the compiler and oracle efforts or to any of the IDE plugins, that would be awesome. Again, you can find links to all these projects on the IDE webpage).
Questions
Does this seem like good plan? How about the technical side of things - what have we missed or got wrong?
Do you have opinions on prioritisation?
Are you interested and want to help out? Is there anything particular you’d like to help with? (Especially if that is something that hasn’t been covered here).
Is there anything we can do to better support IDE efforts in the community?
If you’re interested in IDE or editor integration which is not based on Eclipse/Visual Studio/IntelliJ, how can we make sure these efforts are useful to you? (We really want to make sure our support for tools like IDEs is as widely applicable as possible).
Anything else?
