auto merge of #16487 : steveklabnik/rust/guide_ownership, r=brson

Whew. This section was so important, I saved it for last.

/cc @wycats, @nikomatsakis
auto merge of #16631 : pcwalton/rust/unboxed-closures-wrong-trait, r=huonw

the right trait and take the method name into account.

Closes #16599.

r? @huonw
bitv: make benchmarks always return a value

This makes sure that the benchmarked code does not get optimized away.
Also fixed a typo.

Fixes #12118.
arena: fix a typo
bitv: make sure benchmarks run long enough

Previously they were too short (less than 10 ns), so the benchmarker
could not resolve them meaningfully. Now they should run in the order of
100 ns.
auto merge of #16632 : pcwalton/rust/unboxed-closures-euv, r=luqmana

expression use visitor.

Closes #16166.

r? @huonw
fix module wording in guide

@kimundi was a bit worried this was misleading.
Fix FFI guide
librustc: Create unboxing shims as necessary for unboxed closures.

Closes #16591.
auto merge of #16499 : cmr/rust/struct-undef-repr, r=pcwalton

r? @pcwalton
Parameterize indent in PrettyEncoder
librustc: Mark unboxed closure calls and definitions with appropriate llvm return/argument attributes.
auto merge of #16601 : cybergeek94/rust/master, r=alexcrichton

Previously, `PrettyEncoder` indented a magic constant of 2 spaces per level, which may be fine for most uses but in my use case I would like to allow the user to specify the indent step for the outputted JSON in my program.

This is small change that does not break any existing code whatsoever, and does not change the behavior of existing uses. `PrettyEncoder::new()` still uses the default of 2.

I couldn't think of any simple tests for this change. The obvious one would be to check the outputted JSON for the correct number of spaces per indent level, but I think that would be more complex than the actual change itself and test little besides correctness and consistency, which can be verified visually. There's already a test for correct parsing of pretty-printed JSON that should still pass with this change.
auto merge of #16635 : steveklabnik/rust/ordering_comment, r=huonw

This way people won't try to copy/paste it in.

This is provided as an alternate solution to #16003. What do you think, @treeman?
Fix LLVM version in configure

Upstream LLVM from VCS already has version 3.6,
configure fixed appropriately to allow building with it
syntax: Fix complexity of string parsing. Closes #16624.
auto merge of #16637 : pcwalton/rust/unboxed-closures-expected-tuple, r=pnkfelix

code wasn't considering the zero-argument case.

Closes #16168.

r? @pnkfelix
syntax: Test parsing of long binary strings
Use only 400000 characters to test slow string parsing.
make priorityqueue's from_iter use heapify