instead of prefix `..`.
This breaks code that looked like:
match foo {
[ first, ..middle, last ] => { ... }
}
Change this code to:
match foo {
[ first, middle.., last ] => { ... }
}
RFC #55.
Closes#16967.
[breaking-change]
This breaks code that uses the `..xs` form anywhere but at the end of a
slice. For example:
match foo {
[ 1, ..xs, 2 ]
[ ..xs, 1, 2 ]
}
Add the `#![feature(advanced_slice_patterns)]` gate to reenable the
syntax.
RFC #54.
Closes#16951.
[breaking-change]
Closes#16813
r? @nikomatsakis I feel like I should be checking more things in check_rvalues, but not sure what - I don't properly understand expr_use_visitor
This code used to produce an ICE on the definition of trait Bar
with the following message:
Type parameter out of range when substituting in region 'a (root
type=fn(Self) -> 'astr) (space=FnSpace, index=0)
Closes#16218.
This branch adds support for running LLVM optimization and codegen on different parts of a crate in parallel. Instead of translating the crate into a single LLVM compilation unit, `rustc` now distributes items in the crate among several compilation units, and spawns worker threads to optimize and codegen each compilation unit independently. This improves compile times on multicore machines, at the cost of worse performance in the compiled code. The intent is to speed up build times during development without sacrificing too much optimization.
On the machine I tested this on, `librustc` build time with `-O` went from 265 seconds (master branch, single-threaded) to 115s (this branch, with 4 threads), a speedup of 2.3x. For comparison, the build time without `-O` was 90s (single-threaded). Bootstrapping `rustc` using 4 threads gets a 1.6x speedup over the default settings (870s vs. 1380s), and building `librustc` with the resulting stage2 compiler takes 1.3x as long as the master branch (44s vs. 55s, single threaded, ignoring time spent in LLVM codegen).
The user-visible changes from this branch are two new codegen flags:
* `-C codegen-units=N`: Distribute items across `N` compilation units.
* `-C codegen-threads=N`: Spawn `N` worker threads for running optimization and codegen. (It is possible to set `codegen-threads` larger than `codegen-units`, but this is not very useful.)
Internal changes to the compiler are described in detail on the individual commit messages.
Note: The first commit on this branch is copied from #16359, which this branch depends on.
r? @nick29581
- Ensures the propagated negation sign is properly utilized during type
checking.
- Removed redundant type checking, specifically regarding the out of bounds checking
on a bounded type.
- Closes#16684
Use '^' to specify center alignment in format strings.
```
fmt!( "[{:^5s}]", "Hi" ) -> "[ Hi ]"
fmt!( "[{:^5s}]", "H" ) -> "[ H ]"
fmt!( "[{:^5d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^5d}]", -1i ) -> "[ -1 ]"
fmt!( "[{:^6d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^6d}]", -1i ) -> "[ -1 ]"
```
If the padding is odd then the padding on the right will be one
character longer than the padding on the left.
Use '^' to specify center alignment in format strings.
fmt!( "[{:^5s}]", "Hi" ) -> "[ Hi ]"
fmt!( "[{:^5s}]", "H" ) -> "[ H ]"
fmt!( "[{:^5d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^5d}]", -1i ) -> "[ -1 ]"
fmt!( "[{:^6d}]", 1i ) -> "[ 1 ]"
fmt!( "[{:^6d}]", -1i ) -> "[ -1 ]"
If the padding is odd then the padding on the right will be one
character longer than the padding on the left.
Tuples squashed
They were only correct in the simplest case. Some of the optimisations
are certainly possible but should be introduced carefully and only
when the whole pattern codegen infrastructure is in a better shape.
Fixes#16648.
closes#16800
r? @nikomatsakis - I'm not 100% sure this is the right approach, it is kind of ad-hoc. The trouble is we don't have any intrinsic notion of which types are sized and which are not, we only have the Sized bound, so I have nothing to validate the Sized bound against.
Fixes#16597
I'm not 100% sure this is the correct way to handle this - but I wasn't able to find a better way without doing way more refactoring of the code that I was comfortable with. Comments and criticism are appreciated 😄
The tcp-accept-stress, despite the previous modifications, is still deadlocking
on the osx buildbots. When building/testing/running repeatedly locally, it was
discovered that the test would often fail with TcpStream::connect returning the
error `address not available`.
This test opens up quite a large number of sockets, and it looks like by default
osx isn't the speediest at recycling those sockets for further use.
The test has been modified (and verified) to not deadlock in this error case,
and the test is not just officially ignored on OSX (with no FIXME). I believe
that we'll get good coverage of the relevant code on the linux builders, so this
isn't so much of a loss.
At the same time I turned down the stress parameters to hopefully lighten the
socket load on other platforms.
