11 April 2018

Rust all-hands (dev-tools stuff)

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.

Full notes

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.

Full notes.

Custom test frameworks

IDE planning

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.

Full notes

Cargo

The Cargo team discussed:

custom registries
profiles
public dependencies
build system and RLS integration (build plans)
templates
project-scoped custom commands

Xargo

We discussed how to better support cross-compilation in Cargo without requiring Xargo. This probably means bringing Xargo entirely into Cargo.

Rustup

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.

Compiler consumers

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.

Libsyntax 2

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.

Doxidize

Steve demo'ed Doxidize a possible successor/alternative to Rustdoc. It supports richer documentation including docs beyond API docs such as guides and examples.