What will become of the 215 issues marked A-rustdoc in the rust-lang/rust repo? Is the intent of this project to obviate all of them?

[bstrie]

A quite large proportion of the issues on the official Rust repo are for rustdoc: bugs, suggestions, and feature requests. Is the intent of this tool to be a perfectly-compatible, drop-in, bug-for-bug replacement of its precursor? If not, has there been any attempt to sift through the open issues and pick out the requested enhancements and design them into the tool from the ground-up?

https://github.com/rust-lang/rust/labels/A-rustdoc

[mgattozzi]

I think there's a few ways to sift through them (and I don't think any of us have yet) and tag them:

1. Bugs - If it's a bug it's for the old rustdoc and once it gets replace these can be closed
2. Suggestions - If they've been implemented in the new one they can be closed otherwise best to keep open
3. Feature Requests - In much the same way as suggestions it depends on if they're implemented along the way to feature parity or not.

I don't think the intent is to be a complete bug-for-bug replacement. I think it's just to get this version looking and acting the same at least. This might mean we keep some of the same bugs somehow or inadvertently fixing them.

The main thing here is that the categorization of all the above issues depends on this rustdoc getting to feature parity which is the first goal. It may subsume or close issues in the process. At this point no one has gone through to pick what would be good to include.

[steveklabnik]

We're very far off from being able to even consider these things. It's not clear if, once this is good enough, it will go back into the Rust repo, or if we'll always keep it separate and say, move it into the rust-lang org. It's not 100% clear if we intend to make the UI an exact copy or not.

has there been any attempt to sift through the open issues and pick out the requested enhancements and design them into the tool from the ground-up?

Only to some degree; I'm familiar with all of those bugs, so they're on my mind, but at the same time, we're not yet at the stage where we can even work on implementing that stuff. Many of them aren't "from the ground up" things, or at least, not with the implementation strategy we've planned; that is, many of them are front-end requests, and we've mostly been working on getting the backend solid.