The previous wording was confusing. While would we need to go through
the whole list just to find the first code point? `chars()` being an
iterator, we only need to walk from the beginning of the list.
Note that I am not a native English speaker and I have still difficulties to spot if a "the" is needed somewhere. Feel free to take this PR as a mere suggestion.
r? @steveklabnik
This commit removes all morestack support from the compiler which entails:
* Segmented stacks are no longer emitted in codegen.
* We no longer build or distribute libmorestack.a
* The `stack_exhausted` lang item is no longer required
The only current use of the segmented stack support in LLVM is to detect stack
overflow. This is no longer really required, however, because we already have
guard pages for all threads and registered signal handlers watching for a
segfault on those pages (to print out a stack overflow message). Additionally,
major platforms (aka Windows) already don't use morestack.
This means that Rust is by default less likely to catch stack overflows because
if a function takes up more than one page of stack space it won't hit the guard
page. This is what the purpose of morestack was (to catch this case), but it's
better served with stack probes which have more cross platform support and no
runtime support necessary. Until LLVM supports this for all platform it looks
like morestack isn't really buying us much.
cc #16012 (still need stack probes)
Closes#26458 (a drive-by fix to help diagnostics on stack overflow)
r? @brson
This commit removes all morestack support from the compiler which entails:
* Segmented stacks are no longer emitted in codegen.
* We no longer build or distribute libmorestack.a
* The `stack_exhausted` lang item is no longer required
The only current use of the segmented stack support in LLVM is to detect stack
overflow. This is no longer really required, however, because we already have
guard pages for all threads and registered signal handlers watching for a
segfault on those pages (to print out a stack overflow message). Additionally,
major platforms (aka Windows) already don't use morestack.
This means that Rust is by default less likely to catch stack overflows because
if a function takes up more than one page of stack space it won't hit the guard
page. This is what the purpose of morestack was (to catch this case), but it's
better served with stack probes which have more cross platform support and no
runtime support necessary. Until LLVM supports this for all platform it looks
like morestack isn't really buying us much.
cc #16012 (still need stack probes)
Closes#26458 (a drive-by fix to help diagnostics on stack overflow)
The previous wording was confusing. While would we need to go through
the whole list just to find the first code point? `chars()` being an
iterator, we only need to walk from the beginning of the list.
Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to make references more obvious, without using a character with actual meaning in the rust language (like `&` or previously `~`).
'work' can refer to the game itself, ie, 'this compiles but the game isn't finished,'
so 'compile' is a more clear way to describe the problem.
Thanks jhun on irc
'work' can refer to the game itself, ie, 'this compiles but the game isn't finished,'
so 'compile' is a more clear way to describe the problem.
Thanks jhun on irc
- Move "Destructuring" after "Multiple patterns", because some of
later sections include examples which make use of destructuring.
- Move "Ignoring bindings" after "Destructoring", because the former
features Result<T,E> destructuring. Some of examples in later
sections use "_" and "..", so "Ignoring bindings" must be
positioned before them.
- Fix#27347 by moving "Ref and mut ref" before "Ranges" and
"Bindings", because "Bindings" section includes a somewhat
difficult example, which also makes use of "ref" and "mut ref"
operators.
- Move "Destructuring" after "Multiple patterns", because some of
later sections include examples which make use of destructuring.
- Move "Ignoring bindings" after "Destructoring", because the former
features Result<T,E> destructuring. Some of examples in later
sections use "_" and "..", so "Ignoring bindings" must be
positioned before them.
- Fix#27347 by moving "Ref and mut ref" before "Ranges" and
"Bindings", because "Bindings" section includes a somewhat
difficult example, which also makes use of "ref" and "mut ref"
operators.
- Fix#26968 by noting the difference between ".." and "_" more explicitly
- Change one of the examples to show the match-all behaviour of ".."
- Merge "Ignoring variants" and "Ignoring bindings" sections into the latter
r? @steveklabnik
Clarifications for those new to Rust and Cargo:
* It's a good idea to get rid of the original `main.exe` in project root
* Slight clarification on the use of `main.rs` vs `lib.rs`
* Clarify that the TOML file needs to be in project root
- Fix#26968 by noting the difference between ".." and "_" more explicitly
- Change one of the examples to show the match-all behaviour of ".."
- Merge "Ignoring variants" and "Ignoring bindings" sections into the latter
Squashed at reviewer's request:
Add heading at the end of the introductory material
Spice up introductory paragraphs a bit
Use quotes instead of <code> for phrase
Remove "other" in "other restrictions" (it's not obvious that any other
restrictions have been mentioned)
"Default methods" is a second-level heading, but is not a subsection of
"Where clause"
Reword "Default methods" introduction: it's not the "last feature" on
this page
This includes a new example with Rectangle, instead of reusing HasArea,
because fn area would require the Mul trait, and the added complexity of
that would be better left for the Operators and Overloading chapter.
Squashed at reviewer's request: Move teaser for trait bounds to bottom
Guessing Game states that "Rust only imports a few things into every
program, the ‘prelude’". That isn't strictly true. That is all it
imports by default and the change clarifies that point.
Added definitions for 'Expression', 'Expression-Oriented Language' and 'Statement' to glossary.
Sorted the definitions alphabetically.
r? @steveklabnik
The reader could probably infer this from the current text, but for C++ programmers it's not obvious that struct fields don't automatically become public.
Apparently I wasn't the only one to be confused:
http://stackoverflow.com/questions/29157300/field-of-struct-is-private-when-importing-module
I don't think an example is necessary, but can add one if desired.
r? @steveklabnik
Instead of bar/baz, use valid/invalid as default methods. This
illustrates why you might want default methods, and shows that you can
call other trait methods from a default method.
r? @steveklabnik
Instead of bar/baz, use valid/invalid as default methods. This
illustrates why you might want default methods, and shows that you can
call other trait methods from a default method.
Was browsing somebody else's code and came across a snippet using labels. Looking around, it seems like there was an example for this in [rustbyexample](http://rustbyexample.com/flow_control/loop/nested.html) but none in trpl.
Updated "Installing Rust" and "After installation" to provide additional guidance to Windows users on including Rust in the Path system variable.
r? @steveklabnik
This PR fixes a snippet of code on the error handling chapter of \"The Rust Programming Language\".
//cc @steveklabnik
The docs state that trying to compile the snippet will yield the following error:
```bash
anon>:13:5: 20:6 error: non-exhaustive patterns: `_` not covered [E0004]
```
But instead the error received is:
```bash
<anon>:22:46: 22:56 error: unresolved name `NewRelease`
<anon>:22 std::io::println(descriptive_probability(NewRelease));
^~~~~~~~~~
<anon>:22:5: 22:21 error: unresolved name `std::io::println`
<anon>:22 std::io::println(descriptive_probability(NewRelease));
^~~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
playpen: application terminated with error code 101
```
After applying this PR the expected error is returned:
```bash
anon>:13:5: 20:6 error: non-exhaustive patterns: `_` not covered [E0004]
<anon>:13 match probability(&event) {
<anon>:14 1.00 => \"certain\",
<anon>:15 0.00 => \"impossible\",
<anon>:16 0.00 ... 0.25 => \"very unlikely\",
<anon>:17 0.25 ... 0.50 => \"unlikely\",
<anon>:18 0.50 ... 0.75 => \"likely\",
...
<anon>:13:5: 20:6 help: see the detailed explanation for E0004
error: aborting due to previous error
```
Grammatical update (and passive -> active, but I'm not sure if "Rust" is often used as a subject in the book; feel free to revert that part for style, but keep the subject-verb agreement)
I am not mentioning #[unsafe_drop_flag] because it should go away
eventually, and also because it's just an attribute, it's not
really a use of the `unsafe` keyword.
Fixes#26345
I am not mentioning #[unsafe_drop_flag] because it should go away
eventually, and also because it's just an attribute, it's not
really a use of the `unsafe` keyword.
Fixes#26345
In Chapter 5.9 (References and Borrowing), there is an example [at the very end](https://doc.rust-lang.org/stable/book/references-and-borrowing.html#use-after-free) which shows that declaring a reference before declaring the variable that it points to results in a compilation error. The book does not really mention why this happens though -- in the sections before, it has described how different scopes affects the lifetime of resources, but there is no mention of how resources within the same scope work.
This confused me a little, so I asked on #rust and got the answer that the resources are destroyed in the reverse order that they are declared, but the book makes no mention of it (as far as I can find) -- except in Chapter 5.21 (Drop), where it says:
> When `x` goes out of scope at the end of `main()`, the code for `Drop` will run. `Drop` has one method, which is also called `drop()`. It takes a mutable reference to `self`.
>
> That’s it! The mechanics of `Drop` are very simple, but there are some subtleties. For example, values are dropped in the opposite order they are declared. [...]
---
I feel like Chapter 5.9 (References and Borrowing) is probably the best place to put this information (as I have done in my additions), since it deals with other types of referencing and borrowing. However, since English is not my native language, the wording of my additions perhaps are a little "off" -- any feedback on them is appreciated.
In particular, I found that the disclaimer (promised in the second paragraph) doesn't stand out right now. I think the extra headers help with scanning this document, and making it easier to discern which steps are relevant to my particular flow through the options.
In particular, I found that the disclaimer (promised in the second paragraph) doesn't stand out right now. I think the extra headers help with scanning this document, and making it easier to discern which steps are relevant to my particular flow through the options.
I'm currently reading the rust book and this variable name tripped me up.
Because it was called "input", I thought at first it might contain the line
read by read_line(). This new variable name will be more instructive to rust
beginners.
Use result of the computation to prevent the compiler from optimising
too much. Change `_x` to `x` and therefore remove the paragraph about
the underscore.
Fixes#25855.
r? @steveklabnik
Use result of the computation to prevent the compiler from optimising
too much. Change `_x` to `x` and therefore remove the paragraph about
the underscore.
Fixes#25855.
Explain the --bin flag in terms of the difference
between shipping binary and library code
I'm not sure if my explanation is even quite correct, but as a newbie coming from Ruby, this is my best guess. (In Rubyland, libraries always ship with the source code because there's no other form you can ship. :) )
In the discussion of returning closures, it seems like the example code got simplified, but only the later copies got fixed. The final working code has `factory` returning `|x| x + num`, but the earlier code has `|x| vec.push(x)`.
The first form seemed to have more distracting characteristics, and the code wasn't right anyway, so I changed them to all use the second form, and updated the error messages.
r? @steveklabnik
Doc patch for #26120. Extra words here, because "value" is repeated.
I haven't read about whether/how it should go to stable (sorry), but I think it would help newcomers.
Thanks,
The text claimed 'any borrow must last for a _smaller_ scope than the
owner', however the accurate way of describing the comparison is
inclusive (i.e., 'less than or equal to' vs. 'less than').
For a user following the path of reading Chapter 5: Syntax & Symantics
prior to Chapter 4: Learn Rust, this will be the first time they have
encountered executable tests inside documentation comments.
The test will fail because the `add_one` function is not defined in
the context of the doctest. This might not be the optimal place to
introduce and explain the `/// #` notation but I think it is important
that this snippet pass as a test when `rustdoc --test` is run against
it.
The doc indicates that you can replace 'before' with 'after' showing the use of try!. The two examples should be equivalent, but they are not.
In the File::create we were inducing a panic before in case of error, not propagating. It is important for newbies (like myself) to understand that try! propagates failures, while unwrap can induce a panic.
The other alternative is to make the 'before' File::create also manually handle Err like the other calls. Either way it would be consistent.
As mentioned in #25893 the copy trait is not very well explained for beginners. There is no clear mention that all primitive types implement the copy trait and there are not a lot of examples.
With this change I try to make it more visible and understandable for new users.
I myself have struggled with this, see [my question on stackoverflow](http://stackoverflow.com/questions/30540419/why-are-booleans-copyable-even-though-the-documentation-doesnt-indicate-that). And I want to make it more transparent for others.
I filed issue #25893 but I thought that I could give it a shot myself to relieve some of the work from the devs :)
If it is not well written or there are some changes to be made before it can be merged, let me know.
Cheers,
Mathieu
For a user following the path of reading Chapter 5: Syntax & Symantics
prior to Chapter 4: Learn Rust, this will be the first time they have
encountered executable tests inside documentation comments.
The test will fail because the `add_one` function is not defined in
the context of the doctest. This might not be the optimal place to
introduce and explain the `/// #` notation but I think it is important
that this snippet pass as a test when `rustdoc --test` is run against
it if it is going to be shown.
The sensible default used here for the version number in the
auto-generated Cargo.toml is 0.1.0, not 0.0.1 (at least as of cargo
0.2.0-nightly efb482d).
The statement is not completely exact, because it is valid to have
both 0 non-mutable references and 1 mutable reference. Instead, use
the same wording as in mutability.md.
Hi
I added a little section in the for loops about the `enumerate()` function.
I think it's useful for beginners to know this function and how you can use it.
I used the title loopcounter, but it's probably not the best word to describe it. So let me know if there is a better word :)
The statement is not completely exact, because it is valid to have
both 0 non-mutable references and 1 mutable reference. Instead, use
the same wording as in mutability.md.
The doc indicates that you can replace 'before' with 'after' showing the use of try!. The two examples should be equivalent, but they are not.
In the File::create we were inducing a panic before in case of error, not propagating. It is important for newbies (like myself) to understand that try! propagates failures, while unwrap can induce a panic.
The other alternative is to make the 'before' File::create also manually handle Err like the other calls. Either way it would be consistent.
As mentioned in #25893 the copy trait is not very well explained for beginners. There is no clear mention that all primitive types implement the copy trait and there are not a lot of examples.
With this change I try to make it more visible and understandable for new users.
I myself have struggled with this, see [my question on stackoverflow](http://stackoverflow.com/questions/30540419/why-are-booleans-copyable-even-though-the-documentation-doesnt-indicate-that). And I want to make it more transparent for others.
I filed issue #25893 but I thought that I could give it a shot myself to relieve some of the work from the devs :)
If it is not well written or there are some changes to be made before it can be merged, let me know.
Cheers,
Mathieu
Needed to support:
```rust
match X {
pattern if Y ...
}
for pattern in Y {}
```
IMO, this shouldn't require an RFC because it can't interfere with any future language changes (because `pattern if` and `pattern in` are already legal in rust) and can't cause any ambiguity.
