r? @steveklabnik
add examples that lift `<<` and `>>` to a trivial struct
replace `Scalar` structs with struct tuples
add `fn main` wrappers to enable Rust Playground "Run" button
compute and cache HIR hashes at beginning
This avoids the compile-time overhead of computing them twice. It also fixes
an issue where the hash computed after typeck is differen than the hash before,
because typeck mutates the def-map in place.
Fixes#35549.
Fixes#35593.
Some performance measurements suggest this `HashesMap` is very small in memory (unobservable via `-Z time-passes`) and very cheap to construct. I do see some (very minor) performance wins in the incremental case after the first run -- the first run costs more because loading the dep-graph didn't have any hashing to do in that case. Example timings from two runs of `libsyntex-syntax` -- the (1) indicates first run, (2) indicates second run, and (*) indicates both together:
| Phase | Master | Branch |
| ---- | ---- | ---- |
| compute_hashes_map (1) | N/A | 0.343 |
| load_dep_graph (1) | 0 | 0 |
| serialize dep graph (1) | 4.190 | 3.920 |
| total (1) | 4.190 | 4.260 |
| compute_hashes_map (2) | N/A | 0.344 |
| load_dep_graph (2) | 0.592 | 0.252 |
| serialize dep graph (2) | 4.119 | 3.779 |
| total (2) | 4.71 | 4.375 |
| total (*) | 8.9 | 8.635 |
r? @michaelwoerister
I can think of a few things we may want to accomplish with the documentation of the `Fn`, `FnMut`, and `FnOnce` traits:
- the relationship between these traits and the closures that implement them
- examples of non-closure implementations
- the relationship between these traits and Rust's ownership semantics
add module-level documentation for `Fn*` traits
Describe how `Fn*` traits, closure types, and ownership semantics are
linked, and provide examples of higher-level functions that take `Fn*`s.
more examples for `Fn*` traits
create correct (though not yet elegant) examples for `FnMut` and `FnOnce`
add trait links to module-level documentation
third time's a charm!
argument -> capture for trait documentation
This wording will need to be supported with better examples for
capturing eventually.
correct `FnOnce` example
I also fixed some of the trait wording here to make the concept of
capturing clearer; though that still needs more work.
replace `x + x` with `x * 2` for `fn double`
Implement 1581 (FusedIterator)
* [ ] Implement on patterns. See https://github.com/rust-lang/rust/issues/27721#issuecomment-239638642.
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.
Closes: #35602 (Tracking Issue)
Implements: rust-lang/rfcs#1581
Implement `CoerceUnsized` for `{Cell, RefCell, UnsafeCell}`
These impls are analogous to the one for `NonZero`. It's occasionally useful to be able to coerce the cell types when they're being used inside another abstraction. See Manishearth/rust-gc#17 for an example.
r? @eddyb
We want to catch this error:
```
if (foo)
bar;
```
as it's valid syntax in other languages, and say how to fix it.
Unfortunately it didn't care if the suggestion made sense and just
highlighted the unexpected token.
Now it attempts to parse a statement, and if it succeeds, it shows the
help message.
Fixes#35907
