Rollup of 4 pull requests #24195
Merged
Rollup of 4 pull requests #24195
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
steveklabnik
commented
Apr 8, 2015
- Successful merges: Improve extended errors (rustc --explain). #24143, Update 'let is used to introduce variables' paragraph #24149, Remove incorrect example from docs #24167, TRPL: revise the TOC #24178
- Failed merges:
…kfelix I've taken another look at extended errors - fixing up the printing and adding a few more for match expressions. With regards to printing, the previous behaviour was to just print the error message string directly, despite it containing indentation which caused it to overflow the standard terminal width of 80 columns (try `rustc --explain E0004`). The first approach I considered was to strip the leading whitespace from each line and lay out the text dynamically, inserting spaces in between. This approach became quite messy when taking multi-paragraph errors into account (and seemed overkill). The approach I settled on removes the indentation in the string itself and begins each message with a newline that is stripped before printing. I feel like complete extended errors would be nice to have for 1.0.0 and I'm happy to spearhead an effort to get them written. Brian got me onto writing them at an SF meetup and I think it shouldn't be too hard to get the remaining 80 or so written with the help of people who don't really work on compiler innards.
I think "let is used to introduce variables" is incorrent.
You can use
```rust
match (42, true) {
(x, y) => { /* ... */ }
}
```
to replace
```rust
let x = 42;
let y = true;
```
so it's nothing special for `let`.
…om-mpsc, r=steveklabnik As beta is now released and is "suggested" version of `rustc` then there should be no code (in documentation) that will not compile with it. This one does not. So according to [this great talk](http://delete-your-code.herokuapp.com/), I am doing what should be done.
Basically, the overall structure is this: * Getting Started - getting an environment up and running * Learn Rust - project-based learning the basics * Effective Rust - higher level concepts that lead to writing good rust * Syntax and Semantics - chunks of exactly what it sounds like * Nightly Rust - unstable stuff, a staging area for documenting features * Glossary - self-explanatory There's a number of weaknesses with the current TOC, but I'll just focus on the strengths of the new one: We start off with getting our environment set up. That's "getting started". Then, we basically present you with two choices: do you want to start small, with bits of syntax? Or do you want to dive in with projects? I'm guessing more people will choose the second, so that's the next part: "Learn Rust." I don't have any chapters here, but this would have an updated guessing game, a tutorial on building a little `wc` clone, and something else I haven't decided yet. Lots of options. But the idea is to just dive in and get your hands dirty. I'll heavily link to the 'syntax and semantics' sections that are relevant. Then, a section I'm calling 'Effective Rust'. it feels greedy to steal that title, so I'm hoping to give it another name. These are higher-level things than syntax that Rust programmers should know: error handling is a great example. Most of these are sort of 'how do I use the standard library together' kinds of things. This also contains informations about systems programming that those new to it might not know: the stack vs the heap, for example. Then, "Syntax and Semantics." This has one section for each bit of Rust. Small, focused, but explains _everything_. These are positioned to be almost entirely in-order, but heavily cross-link, so you can go out of order if you want to, but you can also use it as a reference. Next, "Nightly Rust," where documenting unstable things goes. If we want to get good feedback on new features, they'll need to be documented, but we don't want to taint the main docs, so that's what this is for. Finally, the glossary. Straightforward enough. -------------------------------- This is going to be a terrible PR to review, so I just did the TOC re-organization, with basically no editing. So it'll be a bit jumbled at first. But next steps are to go through and edit / revise / tweak / add stuff to get it in tip-top shape for 1.0!
|
@bors: r+ p=1 |
|
📌 Commit 12e9d7c has been approved by |
|
(rust_highfive has picked a reviewer for you, use r? to override) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.