Currently, we build a closure that does nothing but pass its argument
through to another function, this is rather wasteful and creates lots of
unnecessary closures.
While it's unstable and will probably be replaced or "reformed" at some point, it's useful in the mean time to be able to introspect the type system when debugging, and not be limited to sized types.
Fixes#21058
...to make it slightly clearer that there's not much point in boxing a vec.
On a different note, I read the contribution guidelines (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-request-procedure) which say I should update the copyright date for this file. But I can see that nobody else has done this so far this year, despite there being a fair number of commits.
Does that instruction need removing?
Really small correction.
This anti-example in the Closures section is supposed to fail because of a borrow, but it was failing at the type inference because of insufficient type information.
This makes it fail for the expected reason.
Just a couple of tweaks to improve the appearance of pages like [The Rust Reference](http://doc.rust-lang.org/reference.html) on mobile to advance the progress of #20850. Changing the viewport wasn't quite good enough to make it mobile-friendly, as large tables forced the page to become wider than the screen width. Using `overflow-x`, tables that are too large become horizontally scrollable instead of forcing the *entire page* to become horizontally scrollable.
Also, there was at least one case where an extremely long piece of inline code was wider than the actual width of the screen (`std::ptr::copy_nonoverlapping_memory`), so I changed `word-wrap` to allow inline code to break in the middle of words instead of only text within `pre` tags.
This isn't a change included in this PR, but rather something up for discussion. Currently, code blocks that contain long lines simply wrap onto the next line. What if rather than wrapping, they were horizontally scrollable instead? I'm not sure what the general preference is regarding this.
r? @steveklabnik
libsyntax compiled without optimization uses a lot of stack, which can cause it to run out of stack space. This PR factors out some arm handlers from `print_expr` as well as converts `advance_left` into a loop. This helps to cut down on the stack usage.
There are two places left where we used to only know the byte
size of/offset into an array and had to cast to i8 and back to get the
right addresses. But by now, we always know the sizes in terms of the
number of elements in the array. In fact we have to add an extra Mul
instruction so we can use the weird cast-to-u8 code. So we should really
just embrace our new knowledge and use simple GEPs to do the address
calculations.
Fixes#3729
