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
