Futureproof Rust for fancier suffixed literals. The Rust compiler tokenises a literal followed immediately (no whitespace) by an identifier as a single token: (for example) the text sequences `"foo"bar`, `1baz` and `1u1024` are now a single token rather than the pairs `"foo"` `bar`, `1` `baz` and `1u` `1024` respectively.
The compiler rejects all such suffixes in the parser, except for the 12 numeric suffixes we have now.
I'm fairly sure this will affect very few programs, since it's not currently legal to have `<literal><identifier>` in a Rust program, except in a macro invocation. Any macro invocation relying on this behaviour can simply separate the two tokens with whitespace: `foo!("bar"baz)` becomes `foo!("bar" baz)`.
This implements [RFC 463](https://github.com/rust-lang/rfcs/blob/master/text/0463-future-proof-literal-suffixes.md), and so closes https://github.com/rust-lang/rust/issues/19088.
As-is, there's no indication that the code examples pop out into a window that runs on `play.rust-lang.org` until you mouse over them. I managed to get to section 4 of the guide before realizing you could do this since it didn't occur to me to mouse over the example text.
cc @rose since we went through the tutorial together and I think it wasn't obvious to her either.
Now that we've done `fail` -> `panic`, I feel bringing back the error handling guide is a good idea. We had one long ago, but it was removed when conditions were removed.
This doesn't cover the new FromError stuff, but I feel like it's already useful in this state, so I'm sending this PR now.
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
As a new user, I spent a while confused when flycheck told me the code sample I'd typed in was invalid. I ended up figuring out some of what comes after the code sample more painfully by myself because there was no indication that it was broken in the text beforehand. This one line change makes it clear that the code following it is an experiment that may not work rather than something to assume just works.
This removes some leftover line-numbering cruft from elided error examples and brings some minor clarifications.
I’m not super happy about the ‘we cannot have two mutable pointers that point to the same memory’ wording (to the best of my understanding we can’t even have one mutable and one immutable), but other attempts to word this were derailing the flow a bit too much.
