bors [Sat, 4 Oct 2014 04:27:05 +0000 (04:27 +0000)]
auto merge of #17754 : O-I/rust/update-guide, r=steveklabnik
Hi,
These are a few small edits to the Guide that I made while reading online. Really well done and approachable.
I have a few questions below, but I don't know if this is the proper place to ask them, so feel free to ignore the below.
1. Trailing commas seem to be a convention in Rust and are used quite a bit throughout the Guide, but are never explicitly mentioned. Maybe adding a short mention about them when they first appear in the Structs section might be helpful to those who are unfamiliar with or don't use them in other languages.
2. In the Iterators section, there is a block of code like this:
My inclination would be to put a comma where the comment is to separate the two arms to get this to compile, but it runs fine either way. Is there a convention on commas for scenarios like this where each arm is enclosed in `{}`?
bors [Sat, 4 Oct 2014 00:17:04 +0000 (00:17 +0000)]
auto merge of #17731 : bkoropoff/rust/unboxed-by-ref, r=pcwalton
This began as an attempt to fix an ICE in borrowck (issue #17655), but the rabbit hole went pretty deep. I ended up plumbing support for capture-by-reference unboxed closures all the way into trans.
Rahul Horé [Fri, 3 Oct 2014 20:40:58 +0000 (16:40 -0400)]
Adds comma
Oddly (to me), this code runs fine without the comma separating the `Some` and `None` arms of the `match` construct. It seems like Rust doesn't require you to separate arms with commas if all the expressions are enclosed in braces.
Brian Koropoff [Fri, 3 Oct 2014 02:43:16 +0000 (19:43 -0700)]
Correctly trans capture-by-ref unboxed closures
Store references to the freevars instead of copies when constructing
the environment and insert an additional load when reading them from
the environment.
Brian Koropoff [Thu, 2 Oct 2014 06:52:19 +0000 (23:52 -0700)]
Fix categorization of upvars of capture-by-reference unboxed closures
In particular, this causes mutation of an upvar to correctly mark
it as mutable during adjustment. This makes borrowck correctly
flag conflicting borrows, etc.
We still seem to generate incorrect code in trans which copies the upvar
by value into the closure. This remains to be fixed.
Alex Crichton [Thu, 2 Oct 2014 22:06:08 +0000 (15:06 -0700)]
syntax: Enable parsing of `const` globals
This rewrites them to the current `ItemStatic` production of the compiler, but I
want to get this into a snapshot. It will be illegal to use a `static` in a
pattern of a `match` statement, so all those current uses will need to be
rewritten to `const` once it's implemented. This requires that the stage0
snapshot is able to parse `const`.
bors [Thu, 2 Oct 2014 23:42:31 +0000 (23:42 +0000)]
auto merge of #17715 : aturon/rust/revert-slice-ops-libs, r=alexcrichton
This PR reverts https://github.com/rust-lang/rust/pull/17620, which caused a significant regression for slices.
As discussed with @alexcrichton, all of the public-facing changes of the earlier PR need to be rolled back, and it's not clear that we should move the libraries over to this new notation yet anyway (especially given its feature-gated status).
Alex Crichton [Thu, 2 Oct 2014 20:50:43 +0000 (13:50 -0700)]
travis: Stop building and testing rust
Instead, only run `make tidy`. The tidy script can run quite quickly, and it's
super annoying to run tests for 50 minutes only to have bors fail with a
"trailing whitespace" error.
Alex Crichton [Thu, 2 Oct 2014 20:50:43 +0000 (13:50 -0700)]
travis: Stop building and testing rust
Instead, only run `make tidy`. The tidy script can run quite quickly, and it's
super annoying to run tests for 50 minutes only to have bors fail with a
"trailing whitespace" error.
Alex Crichton [Thu, 2 Oct 2014 20:14:14 +0000 (13:14 -0700)]
std: Help diagnose a flaky test
This test has recently been failing on the bots, and I'm not entirely sure why.
I haven't been able to reproduce locally or on the bots, so I'm adding some
messages to help diagnose the problem hopefully.
Benjamin Herr [Thu, 2 Oct 2014 18:55:26 +0000 (20:55 +0200)]
native: fix passing errno to parent after fork
The bitshifts were wrong in that they invoked undefined behavior and
only passed the lower byte of the presumed-to-be-32bit errno value.
Apparently all actually possible values for errno happen to be easily
under 256, so this didn't cause any actual problems.
This commit fixes the bitshifts, but doesn't generalize to errno types
that aren't 32bit.