• docs for managing out of tree tools (cargo, rls, ...)
• rustup - auto-renaming of components (e.g., rls-beta -> rls)
• rustup - nightly only components Not necessary if we are not going to keep tools on nightly
• rustup - dependent components (this would be nice, but doesn't need to block)

This is an 'explorative' item on the Rust roadmap, and I think it could have an important tools component. Polishing and maintaining the bindgen experience is an obvious part of this, but perhaps there are opportunities for using tools to make the cross-language better in other areas too.

Rust distribution:

• move to nursery
• move tests back to ui tests
• Wait for RLS/rustfmt distro issues to be worked out #18 (comment)
• Add to Rust repo submodule
  • Add building miri to Rust CI
  • Add miri's tests to Rust CI
• Add to Rust distro for nightly only
• Start recommending the distro version
• Make cargo clippy require rustup component add clippy, clean up cargo clippy's impl
• Clippy 1.0, if it's not happened already (probably will have)
• Turn it on for stable too

First concrete step is to have a webpage (linked from r-l.o) that lists tools and 'good first bugs' for each, plus contacts and some getting started advice.

Add to Rust product:

• Add to Rust repo
• agree on stability criteria
• tests running and passing on CI
• overwrite mode by default
• implement stable/unstable command line arguments (unstable options are now supported, but we need to decide which options should be stable)
• resolve 'warnings for skipped sections'

1.0 - see rust-lang/rustfmt#1860

the Great Big List of rustdoc issues (incomplete; last updated 2017-09-08)

It's no secret that rustdoc needs some love. In terms of Area-based issue tags, A-rustdoc is second only to A-diagnostics for "most open issues". (At least, at time of writing, which is 2017-08-07.) I'd like to work through them from oldest to newest, categorizing them based on how much work they require. I'll include some notes about what i think a given issue needs, based on what i know of rustdoc, and from the existing discussion in the thread.

Issues that require groundwork are those that either need to pull some extra information from the compiler, or generate some brand new information, or restructure the code somehow, or some similar amount of "new work" or refactoring. Sometimes this is just another way to frame a small hurdle, sometimes this is a major roadblock that needs coordination from lots of contributors.

Issues that require legwork are mainly about connecting dots that are already there. Usually these are about printing more information, or adjusting some formatting, or some similarly "minor" work.

Issues that require social work need consensus on something. This may involve an RFC, or just a quick canvassing of the relevant teams or the community at large. Usually if i put something in this category i have a decent idea of what other kind of work is required once consensus is reached, so i'll note that in the triage notes.

Finally, issues that need triage work need more information from the OP, or from a source that isn't me. They're either just vague enough that i haven't seen the precise request, or need to touch on something i'm not that familiar with. If you know how to refine this information, or how to fill a knowledge gap, please let me know so i can re-categorize them!

If you want to work on any of these and want some tips, please let me or any of the other rustdoc peers (@steveklabnik and @GuillaumeGomez) know! We're on IRC in #rust-dev-tools and #rust-docs if you want something a little more synchronous.

(shortcut link to issues i haven't written up here)

metabugs

Any existing "list of related issues" pages can just go in this list.

• Define stability
• Move to the nursery
• Submodule into Rust repo
• Distribute with Rustup - enables stable Rust
• lint audit, leading to 1.0
• More...

Where are we at? Where are going?

We should have a blog post on the Rust blog announcing ourselves, motivating what we do, and giving the roadmap for the rest of the year. Need to agree on the roadmap first (#1).

rust-semverver was migrated from the nursery, to the rust-dev-tools org:

• it's CI has not been working on PRs since (travis and appveyor). I've complained on Discord, PRs comments, etc. many times, but no action has been taken.

• it's tied to the rust toolchain version, so it breaks often. This isn't an issue, what's an issue is when PRs that fix this take weeks to merge, at which point some other rust nightly change has broken the tool.

• a new cargo release removed support for APIs that this library is using, meaning that its stuck using a 5 months old cargo version. These things should be better coordinated: breaking tools without providing / discussing a migration path should not happen by accident.

What are we doing for the rest of 2017? Longer term?

For each tool that is to be 'official' (part of the Repo, distributed via Rustup) we need to define the versioning and stability guarantees (back compat and quality) for that tool.

• RLS
• Rustfmt
• Clippy
• Rustdoc

There's been a lot of activity in trying to improve doctests recently. Most notably, a couple contributors outside the Rustdoc Team have really stepped up to help out: @euclio and @rep-nop. It would be cool to coordinate improvements to doctests so we can plan out our changes and not step on each other's toes.

(I'll try to fill this thread with some ideas that i remember seeing or wanting, but full discussion may have to wait until the All-Hands on February 4-8 so i have dedicated time to think about it. In the meantime, feel free to pitch ideas here!)

This is an issue to collect news about dev tools. If anything is happening, however minor, please leave a comment and let us know. Periodically (apx monthly, depending on how much news we get) I'll edit all the comments into a document, add it to the repo, and post to TWiR (and blog, tweet, etc.), then open a new issue.

The rust repository has a file for fine grained disabling of tools: https://github.com/rust-lang/rust/blob/master/src/tools/toolstate.toml

Currently it allows disabling clippy and miri from being tested or built on Rust's CI. The reason they are in CI, is that they access compiler internals, and we want to know when a PR to rustc breaks the tool.

Historically rls and rustfmt were already built as part of the CI, and if you broke them, you had to

• fix the tool
• open a PR to the tool
• have your PR changed to a long lived branch on the tool repository
• point rustc's submodule to the long lived branch
• wait until your rustc PR is merged
• merge the long lived PR into the tool's master branch

That's a lot of steps and a lot of waiting for tool authors and rustc reviewers and CIs and breakage from other PRs...

With the toolstate.toml, you can

• fix the tool
• open a PR to the tool
• change the toolstate.toml to account for your breakage
• merge your rustc PR
• wait until it hits nightly
• tool authors will merge your tool PR
• anyone can now point rustc's submodule to the tool's master branch in a new PR and reenable the tool in toolstate.toml

The steps might not be fewer, but you don't have to wait around for anybody anymore.

Open issues:

• rls and rustfmt can't be changed to Broken, because they are distributed with rustc
• clippy is not distributed

Even if rls and rustfmt are changed so they stop being distributed with rustc in case they are broken, there are a few questions of how the user experience of that is supposed to be.

1. rustup update nightly will update rustc, but you will have a broken tool (linker errors and whatnot)
2. rustup update nightly will update rustc, and the tool will simply be gone (surprising)
3. rustup update nightly will update rustc and the tool will be replaced by a shell script echoing "This tool is currently not available, please try again later updating your nightly
4. rustup update nightly will abort if there is no newer nightly with your specific combination of components
   • you can remove the tool manually if you still want to update
   • add a force option to have one of the previously mentioned behaviours

While I have anecdotal evidence that ppl like option 4, once we have a few tools and there's a breakage spree, it might be hard to find a nightly where all your tools work

Am I missing some options?

Once we have a plan on how the user experience should be, we can start talking to rustup-ppl to figure out how to teach rustup about partial rustups

For the future, where some tools will be on stable, too, I don't see any issues, because we certainly are able to get clippy building on beta/stable within 6 weeks, and I think all other tools should be capable of doing the same. We could even consider informally requiring lockstep upgrades for PRs just before the beta branching. Or we just backport a fix to the beta branch. So the initial beta might be missing a few tools, but before it becomes stable it'll have all the tools in a working condition.

Tools we wish we had, but don't have time to work on right now. Please indicate the magnitude of the task.

I'm primarily looking for ideas which are not in progress or even on our radar for starting.

It is a hassle and takes ages (because of the bors queue) to update tools in the Rust repo. I would like something more automated. I envisage a tool which:

• runs daily (or maybe weekly, whatever)
• only works on master (not beta channel, etc)
• checks toolstate.toml and the CI for the tool and only updates if both are passing tests
• creates its own branch where it:
  • updates the tools submodules
  • runs the complete test suite (but does not interrupt the bors queue to do so)
  • if we pass, merges at the next opportunity (i.e., we don't interrupt another Rust PR, but we don't wait to re-test, we should check toolstate.toml though)

This should mean tools on nightly are always somewhat up to date. We will not slow down the bors queue in any way. However, it does mean we are merging PRs which have not been fully tested. However, I hypothesise that because we only touch the tools submodules and we wouldn't merge if another PR touches the submodules or toolstate.toml, breakage would be extremely rare.

This is an issue to collect news about dev tools. If anything is happening, however minor, please leave a comment and let us know. Periodically (apx monthly, depending on how much news we get) I'll edit all the comments into a document, add it to the repo, and post to TWiR (and blog, tweet, etc.). Then open a new issue.

We've been playing catch-up with IDE support - it is currently one of the most desired features for Rust, but the core community was pretty late in prioritising development. I want to get ahead of the curve and be working on the next important tool before it becomes necessary and overdue. That means getting a better understanding of what is wanted or missing in the current world.

As we get close to the end of the year, it would be helpful to try to organize a direction to push rustdoc next year. So far we've been fairly free-form about what we work on, but if we have a few overarching goals to point at, it would be easier to try to attract new contributors or to prioritize work.

That said, what does the team want to see from rustdoc in the coming year? Feel free to write up ideas in this thread. I'll start with some comments of my own that are outstanding items or are things that i can think of.

cc @steveklabnik @GuillaumeGomez @ollie27 @onur (since i can't ping rust-lang teams all at once on here 😅)

We don't have a meeting time set yet, however I need a place to jot down things that devtools needs to discuss:

• rehash discussion about role of team
• how to deal with small tools like semverver
• go through all smaller tools and just check up on their maintainership (maybe not during meeting itself)
• how to find and address tool vacuums
• the role of this Github org

feel free to add more!

Leave comments with any news for TWiDT

This is an issue to collect news about dev tools. If anything is happening, however minor, please leave a comment and let us know. Periodically (weekly, or less often, depending on much news we get) I'll edit all the comments into a document, add it to the repo, and post to TWiR (and tweet, etc.). Then open a new issue.

Next meeting at April 16

Topics to be discussed:

• Team checkins
• Alternate tooling nightly channel (@kinnison)
• Devtools vacuums and other feedback (@spacekookie)
• Better collaborating with release announcements wrt changelogs

Probably should be pretty light.

cc @killercup @GuillaumeGomez @kinnison @ehuss @Xanewok @oli-obk

To ride the trains:

• tests are testing on Rust CI (rust-lang/rust#42146)
• rename (possibly automatically) rls component to rls-preview
• De facto unstable features are behind the unstable features option
• Unstable features option is linked to nightly toolchain
• Decide on name of the Rustup component (proposed: rls-preview)
• Proper channel info from --version.
• Use the rls-rustc shim (rust-lang/rls#435)

1.0:

• Quality - waiting on bug reports from stable channel release
• Cargo project coverage - lib + bin, workspaces
• Better testing (better protocol coverage, prevent regressions due to compiler data)
• new features - TBD

Essentially nobody is using tools on the beta channel. The effect of this is that tools are hitting the stable channel with fairly serious bugs (e.g., rust-lang/rust#50646, rust-lang/rustfmt#2695).

We need to do something to address this, either:

• encourage users on beta
• add QA to ensure the tools on beta are bug-free
• reorganise how we map tools versions to Rust channels some how.

There haven't been changes in years. Should this be archived?

Just collecting ideas at this point. Some time around the 1.0 launch we should start prioritising and move discussion to the rustfmt repo.

cc @topecongiro

This issue is a fork from rust-lang/rustfmt#4228 (comment) regarding some changes to rustfmt.

The high-level questions are:

• What kind of autonomy does each dev-tools team have?
• What kind of process should each team follow?
• What kind of changes require soliciting community feedback (via processes like RFC or FCP, etc.)?
• What are the stability requirements of Rust tooling?
• What kind of criteria is used for making changes in stable vs nightly (unstable)?

AFAIK, the RFC guidance only discusses language changes, but not tooling changes. Rustfmt has its own formatting RFCs, but that doesn't help with guidance on other changes.

Should we:

• write down guidelines (similar to these) for when an RFC is required?
• write down guidelines and requirements of tool stability? (Including deprecation/removal process, etc.)

I personally think that Rust tools have had a culture initiated by the early developers of maintaining a high standard of backwards-compatibility. I think this is in some ways influenced by the Rust language and library teams having extremely high standards for backwards compatibility. But I don't think that has ever been written down as a requirement or guideline for the tools teams. It might also be worthwhile to explore if different tools might have different requirements for stability and backwards-compatibility.

cc @calebcartwright @killercup @Manishearth @fitzgen @kinnison @GuillaumeGomez @oli-obk @Xanewok

The first item on the Rust roadmap is "Rust should have a lower learning curve". I think tools can be a part of that, and I'm keen to see if there are innovative ways we can support this goal.

What is the status of debugging Rust programs? How can we improve? Should include tools like profiling which are backed off debuginfo.