Last week (sigh, the week before last now) we held an 'all-hands' event in Berlin. It was a great event - fantastic to meet so many Rust people in real life and really energising to see how much is being planned and implemented. There is a blog post describing the whole event on the Rust blog.
In this post I want to summarise some of the important dev-tools stuff that happened. Our planning and notes from some meetings is in the dev-tools team repo.
2018 edition planning
We discussed how the edition transition would affect various tools and how the dev-tools team would ensure we coped with the transition. We also discussed how the Rustfix tool would make the transition easier for users.
Clippy lint audit
We planned an audit of Clippy's lints in preparation for a 1.0 release. The expectation is that we'll keep the current categories of lints and add a new category for unstable lints.Mostly lints would be moved to being off by default. The Clippy team were open to moving some compiler lints to Clippy, but we felt that moving all lints to Clippy was going too far.
The Clippy team will being auditing lints immediately and hope to have an RFC or other document prepared by September. Some work has already been done.
Custom test frameworks
See also the RFC.
We basically just discussed details of the planned implementation.
We discussed a whole bunch of things that we might consider doing post-RLS-1.0. We decided that a debug mode (probably before 1.0, actually), testing (of the RLS), and low-hanging feature fruit would be our priorities. Although we'd like compiler-backed code completion, it is probably not happening soon, and mostly Racer is good enough for now.
The Cargo team discussed:
- custom registries
- public dependencies
- build system and RLS integration (build plans)
- project-scoped custom commands
We discussed how to better support cross-compilation in Cargo without requiring Xargo. This probably means bringing Xargo entirely into Cargo.
We discussed moving toolchain management from Rustup into Cargo. We decided we probably wouldn't try and move all of Rustup into Cargo, but go for an 80/20 split where most users wouldn't need to explicitly use Rustup.
Lots of tools and other consumers want access to the compiler's data. We enumerated them and discussed how to make this data available in a disciplined and more stable form than currently available. The API we decided on is an extension and replacement to the current save-analysis API which is used by the RLS and others. It will be based on the queries used internally in the compiler, but the public queries will generally be higher-level.
A long-term proposal to improve tooling by providing an alternate AST library that would power tools and (probably) the compiler (maybe useful for procedural macros, etc.). It would be optimised for IDEs and similar tools. We decided there were some good goals and interesting ideas here, but that there is no short-term application, so this is low priority for now.
See also the RFC
Steve demo'ed Doxidize a possible successor/alternative to Rustdoc. It supports richer documentation including docs beyond API docs such as guides and examples.
See also the implementation