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?
