This wasn't marked inline, so wasn't being inlined cross-crate. It's
actually a no-op function, since it's a wrapper around `mem::transmute`.
Marking it inline means that programs calling it can see that it's a
no-op and act accordingly during optimisation.
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 :)
This wasn't marked inline, so wasn't being inlined cross-crate. It's
actually a no-op function, since it's a wrapper around `mem::transmute`.
Marking it inline means that programs calling it can see that it's a
no-op and act accordingly during optimisation.
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.
Issue: https://github.com/rust-lang/rust/issues/25969
Compare the span on the stable branch (correct) with the span on the nightly branch (incorrect) for the following example: http://is.gd/lTAo9c. This pull request fixes the regression.
@Manishearth has been kind enough to pitch some ideas for a regression test, mainly revolving around testing the span in compile-fail test, but this has proven unsuccessful. Other suggestions/ ideas would be much appreciated!
The API documentation is not explicit enough that because `try!` returns
`Err` early for you, you can only use it in functions that return
`Result`. The book mentions this, but if you come across `try!` outside
of the book and look it up in the docs, this restriction on the return
type of the function is not particularly clear.
I seriously had this epiphany a few days ago after working with Rust for MONTHS, and after seeing [a friend have to come to the same realization](http://joelmccracken.github.io/entries/a-simple-web-app-in-rust-pt-2a/), I'd like to save more people from this confusion :) 💖
Fix the dropck doc formatting to avoid hitting four-space indent.
This was causing `rustdoc` to interpret the part starting with `(A.) ...` as a code block based on its four-space indentation, which then was treated by `rustdoc` as a *Rust* code snippet, and thus was attempting (and failing) to parse my english as Rust code. Thus causing the compiler-docs build to fail.
Independently, we should probably change `rustdoc` to not interpret four-space indents as code that needs to be tested; it seems too perilous to me at least.
(But the formatting here needed to be changed either way.)
cc Issue #25699.
My main sources of information are [RFC401](https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md), the rust IRC channel, and a bunch of experiments to figure out what `rustc` currently supports.
Note that the RFC calls for some coercion behaviour that is not implemented yet (see #18469).
The documentation in this PR mostly covers current behaviour of rust and doesn't document the future behaviour. I haven't written about receiver expression coercion.
I would be happy to rewrite/adapt the PR according to feedback.
r? @steveklabnik
Part of #24407.
Currently the diagnostics for range patterns are a bit wrong:
```rust
fn main() {
match 5u32 {
0 ... 10 => (),
'a' ... 10 => (),
10 ... 'z' => (),
"what" ... 10 => (),
"what" ... "well" => (),
10 ... "what" => ()
}
}
```
```
range.rs:4:9: 4:19 error: mismatched types in range:
expected integral variable,
found char [E0211]
range.rs:4 'a' ... 10 => (),
^~~~~~~~~~
range.rs:4:9: 4:16 error: only char and numeric types are allowed in range [E0029]
range.rs:4 'a' ... 10 => (),
^~~~~~~
range.rs:4:9: 4:19 error: mismatched types:
expected `u32`,
found `char`
(expected u32,
found char) [E0308]
range.rs:4 'a' ... 10 => (),
^~~~~~~~~~
range.rs:5:9: 5:19 error: mismatched types in range:
expected char,
found integral variable [E0211]
range.rs:5 10 ... 'z' => (),
^~~~~~~~~~
range.rs:5:9: 5:15 error: only char and numeric types are allowed in range [E0029]
range.rs:5 10 ... 'z' => (),
^~~~~~
range.rs:6:9: 6:22 error: mismatched types in range:
expected integral variable,
found &-ptr [E0211]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~~~~
range.rs:6:9: 6:19 error: only char and numeric types are allowed in range [E0029]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
range.rs:6:9: 6:22 error: mismatched types:
expected `u32`,
found `&'static str`
(expected u32,
found &-ptr) [E0308]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~~~~
range.rs:7:9: 7:19 error: only char and numeric types are allowed in range [E0029]
range.rs:7 "what" ... "well" => (),
^~~~~~~~~~
range.rs:7:9: 7:26 error: mismatched types:
expected `u32`,
found `&'static str`
(expected u32,
found &-ptr) [E0308]
range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
range.rs:8:9: 8:22 error: mismatched types in range:
expected &-ptr,
found integral variable [E0211]
range.rs:8 10 ... "what" => ()
^~~~~~~~~~~~~
range.rs:8:9: 8:15 error: only char and numeric types are allowed in range [E0029]
range.rs:8 10 ... "what" => ()
^~~~~~
error: aborting due to 12 previous errors
```
The problems here are:
1. The type of the end of the range is used to predict the type of the start (only mildly counter intuitive).
2. E0029 is erroneously generated for `char ... num` and `num ... char`.
2. `u32` is mentioned.
3. Errors which are essentially the same are reported multiple times.
I've attempted to fix this by checking the requirements in a different order. The output I've achieved for the above example is:
```
/home/michael/Temp/range.rs:4:17: 4:22 error: mismatched types in range:
expected char,
found integral variable [E0211]
/home/michael/Temp/range.rs:4 'a' ... 10 => (),
^~~~~
/home/michael/Temp/range.rs:5:16: 5:22 error: mismatched types in range:
expected integral variable,
found char [E0211]
/home/michael/Temp/range.rs:5 10 ... 'z' => (),
^~~~~~
/home/michael/Temp/range.rs:6:9: 6:19 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
/home/michael/Temp/range.rs:6:9: 6:19 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:6:9: 6:19 note: Start type: &'static str
End type: _
/home/michael/Temp/range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
/home/michael/Temp/range.rs:7:9: 7:26 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
/home/michael/Temp/range.rs:7:9: 7:26 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:7:9: 7:26 note: Start type: &'static str
End type: &'static str
/home/michael/Temp/range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
/home/michael/Temp/range.rs:8:16: 8:25 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:8 10 ... "what" => ()
^~~~~~~~~
/home/michael/Temp/range.rs:8:16: 8:25 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:8:16: 8:25 note: Start type: _
End type: &'static str
/home/michael/Temp/range.rs:8 10 ... "what" => ()
^~~~~~~~~
error: aborting due to 5 previous errors
```
I think this is already tonnes better, but the `Start type/End type` stuff could be neater. I don't think there's really any need to start a `note:` block but I wanted to get some feedback on this. I'd also appreciate advice on how to print the integer types as something other than `_`.
