Update if-let.md
Calling if-let a combination of if and let is confusing, as some may be led to believe that it's a literal combination, instead of syntactic sugar added to the language as a convenience. What's there to stop someone from thinking if-let is just if and let together?
I do think this article does a good job of implying what's really going on; however, I was only able to notice this after I had begun to understand if/while-let statements, courtesy of the Rust IRC chat.
Basically, this article lacks the clarity and explicitness an inexperienced programmer like me needs in order to understand the contents fully. This is shown by my inability to understand the if-let concept from this page of the Book alone.
I think convenience, sugar, and (if-let != if + let) should all be made mention of in a clear, explicit manner. I lack confidence in my understanding of this issue, so I wrote just enough to hopefully get my thoughts across.
rustdoc: fix doctests with non-feature crate attrs
Fixes#38129.
The book says that any top-level crate attributes at the beginning of a doctest are moved outside the generated `fn main`, but it was only checking for `#![feature`, not `#![`.
These attributes previously caused warnings but were then ignored, so in theory this could change the behavior of doctests in the wild.
Extend Cell to work with non-Copy types
I'm not sure that I did this right but all of the tests pass.
I also had to move the `new()` function so that `Cell`s with non-`Copy` `T`s could be created. That wasn't in the RFC but I assume it needed to be done?
Improve doc cfg(test) and tests directory
Hi,
I was facing a problem with my code organisation. I was using a tests directory and i defined some `#[cfg(test)]` in my `src/`. But i was not able to use it in my `tests` folder.
```bash
.
├── Cargo.lock
├── Cargo.toml
├── src
│ ├── lib.rs
│ └── test.rs
└── tests
└── x.rs
```
> src/lib.rs
```rust
pub mod test;
fn tesst() {
assert!(test::t());
}
```
> src/test.rs
```rust
pub fn t() -> bool { true }
```
> test/x.rs
```rust
extern crate testt;
use testt::test;
fn tesst() {
assert!(test::t());
}
```
I was unable to compile using `cargo test`:
```bash
error[E0432]: unresolved import `testt::test`
--> tests/x.rs:3:5
|
3 | use testt::test;
| ^^^^^^^^^^^ no `test` in `testt`
```
If i remove the `tests` directory everything works fine. To use an utils module in your `tests` directory, you need to create a module in the directory (like `tests/utils.rs`). My `tests/x.rs` look like this now:
```rust
extern crate testt;
mod utils;
fn tesst() {
assert!(utils::t());
}
```
And my tree:
```bash
.
├── Cargo.lock
├── Cargo.toml
├── src
│ └── lib.rs
└── tests
├── utils.rs
└── x.rs
```
I think that thing must be documented in the book.
Ping:
- @badboy : Because he's the one who showed me the path
- @shahn : Because he helped me too to find the solution
Signed-off-by: Freyskeyd <simon.paitrault@iadvize.com>
book: size and align in trait object vtables are used
The book currently claims that the `size` and `align` fields in the
trait object vtable are not used, but this is false. These two fields
are used by the stable `mem::size_of_val` and `mem::align_of_val`
functions.
See the `ty::TyDynamic` case of the `glue::size_and_align_of_dst`
function in librustc_trans, which is used to implement both intrinsics
in the unsized case.
r? @steveklabnik
book: match enum warning
Matching enums with named fields in the previous way yielded the "non_shorthand_field_patterns" warning.
The new code shows the shorthand syntax as well as field renaming, so it should be exhaustive ;-)
The book currently claims that the `size` and `align` fields in the
trait object vtable are not used, but this is false. These two fields
are used by the stable `mem::size_of_val` and `mem::align_of_val`
functions.
See the `ty::TyDynamic` case of the `glue::size_and_align_of_dst`
function in librustc_trans, which is used to implement both intrinsics
in the unsized case.
book: use abort() over loop {} for panic
Due to #28728 `loop {}` is very risky and can lead to fun debugging experiences such as #38136. Besides, aborting is probably better behavior than an infinite loop.
r? @steveklabnik
Due to #28728 loop {} is very risky and can lead to fun debugging experiences like in #38136. Besides, aborting is probably better behavior than an infinite loop.
These are some bare-bones documentation for custom derive, needed
to stabilize "macros 1.1",
https://github.com/rust-lang/rust/issues/35900
The book chapter is based off of a blog post by @cbreeden,
https://cbreeden.github.io/Macros11/
Normally, we have a policy of not mentioning external crates in
documentation. However, given that syn/quote are basically neccesary
for properly using macros 1.1, I feel that not including them here
would make the documentation very bad. So the rules should be bent
in this instance.
Use more specific panic message for &str slicing errors
Separate out of bounds errors from character boundary errors, and print
more details for character boundary errors.
It reports the first error it finds in:
1. begin out of bounds
2. end out of bounds
3. begin <= end violated
3. begin not char boundary
5. end not char boundary.
Example:
&"abcαβγ"[..4]
thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not
a char boundary; it is inside 'α' (bytes 3..5) of `abcαβγ`'
Fixes#38052
Matching enums with named fields in the previous way yielded the "non_shorthand_field_patterns" warning.
The new code shows the shorthand syntax as well as field renaming, so it should be exhaustive ;-)
Use "an" before "i32"
(Minor typo fix.)
Since the word `i32` starts with a vowel, the indefinite article should use "an", not "a" \[[1](http://www.dictionary.com/browse/an)\]. (Previously there was one instance of "an i32" and two instances of "a i32", so at least something is wrong!) Since I believe that "an" is the correct form, I aligned everything with that.
Add missing apostrophe.
(Minor typo fix.)
The "support" in this case is possessed by the "programmer", and that ownership should be indicated by an apostrophe.
(Minor typo fix.)
Since the word `i32` starts with a vowel, the indefinite article should use "an", not "a" \[[1](http://www.dictionary.com/browse/an)\]. (Previously there was one instance of "an i32" and two instances of "a i32", so at least something is wrong!) Since I believe that "an" is the correct form, I aligned everything with that.
Fix Markdown list formatting.
The Markdown engine used by the book can cope with a single leading space on the list marker:
Like this:
* List item
Rather than like this:
* List item
… but it’s not the typical convention employed in the book, and moreover the Markdown engine used for producing the error index *can’t* cope with it (its behaviour looks like a bug, as it appears to lose one of the two line breaks as well, but that’s immaterial here).
So, we shift to a single convention which doesn’t trigger bugs in the Markdown renderer.
----
See https://doc.rust-lang.org/error-index.html#E0458 and https://doc.rust-lang.org/error-index.html#E0101 for the bad current rendering in the error index.
Simplify notes on testing and concurrency
The start of the notes on tests running concurrently, added in https://github.com/rust-lang/rust/pull/37766 read a little awkwardly. This PR fixes that and simplifies the wording a bit.
r? @steveklabnik
