bors [Sun, 1 Nov 2015 17:15:29 +0000 (17:15 +0000)]
Auto merge of #29177 - vadimcn:rtstuff, r=alexcrichton
Note: for now, this change only affects `-windows-gnu` builds.
So why was this `libgcc` dylib dependency needed in the first place?
The stack unwinder needs to know about locations of unwind tables of all the modules loaded in the current process. The easiest portable way of achieving this is to have each module register itself with the unwinder when loaded into the process. All modules compiled by GCC do this by calling the __register_frame_info() in their startup code (that's `crtbegin.o` and `crtend.o`, which are automatically linked into any gcc output).
Another important piece is that there should be only one copy of the unwinder (and thus unwind tables registry) in the process. This pretty much means that the unwinder must be in a shared library (unless everything is statically linked).
Now, Rust compiler tries very hard to make sure that any given Rust crate appears in the final output just once. So if we link the unwinder statically to one of Rust's crates, everything should be fine.
Unfortunately, GCC startup objects are built under assumption that `libgcc` is the one true place for the unwind info registry, so I couldn't find any better way than to replace them. So out go `crtbegin`/`crtend`, in come `rsbegin`/`rsend`!
A side benefit of this change is that rustc is now more in control of the command line that goes to the linker, so we could stop using `gcc` as the linker driver and just invoke `ld` directly.
bors [Sun, 1 Nov 2015 07:03:09 +0000 (07:03 +0000)]
Auto merge of #29316 - GBGamer:change-unchecked-div-generic, r=eddyb
Similarly to the simd intrinsics. I believe this is a better solution than #29288, and I could implement it as well for overflowing_add/sub/mul. Also rename from udiv/sdiv to div, and same for rem.
bors [Sat, 31 Oct 2015 04:04:45 +0000 (04:04 +0000)]
Auto merge of #29484 - steveklabnik:gh29330, r=brson
These two commits do a few things:
1. reformat to 80 cols
2. use the reference-style links where appropriate for improved in-source readability
3. adds a few links, tweaks a couple of words, `3` -> `three`, stuff like that
While the diff is big due to these edits, there's no significant content change.
bors [Sat, 31 Oct 2015 00:09:39 +0000 (00:09 +0000)]
Auto merge of #29477 - alexcrichton:revert-compiler-rt, r=brson
This ended up causing regressions in a few builds I've seen:
* MinGW -- [64-bit](https://ci.appveyor.com/project/alexcrichton/gcc-rs/build/1.0.338/job/2c4pkxgxa2dvqs25) and [32-bit](https://ci.appveyor.com/project/alexcrichton/gcc-rs/build/1.0.338/job/d0n7kml3k5el9gla)
- MSVC - [64-bit with VS 12.0](https://ci.appveyor.com/project/alexcrichton/gcc-rs/build/job/ugldcage9ydoy1k6) and [32-bit with VS 12.0](https://ci.appveyor.com/project/alexcrichton/gcc-rs/build/job/pn59p4rhnj8gybei).
I suspect the problems are along the lines of:
* The emutls support needs to be disabled on Windows, it currently always used pthreads which isn't available
* The objects in compiler-rt either need to be built without a CRT or not specifically against the static one.
bors [Fri, 30 Oct 2015 22:23:41 +0000 (22:23 +0000)]
Auto merge of #29454 - stepancheg:vec-reserve, r=bluss
Before this patch `reserve` function allocated twice as requested
amount elements (not twice as capacity). It leaded to unnecessary
excessive memory usage in scenarios like this:
```
let mut v = Vec::new();
v.push(17);
v.extend(0..10);
println!("{}", v.capacity());
```
`Vec` allocated 22 elements, while it could allocate just 11.
`reserve` function must have a property of keeping `push` operation
cost (which calls `reserve`) `O(1)`. To achieve this `reserve` must
exponentialy grow its capacity when it does reallocation.
There's better strategy to implement `reserve`:
```
let new_capacity = max(current_capacity * 2, requested_capacity);
```
This strategy still guarantees that capacity grows at `O(1)` with
`reserve`, and fixes the issue with `extend`.
Stepan Koltsov [Fri, 30 Oct 2015 21:17:16 +0000 (00:17 +0300)]
Fix excessive memory allocation in RawVec::reserve
Before this patch `reserve` function allocated twice as requested
amount elements (not twice as capacity). It leaded to unnecessary
excessive memory usage in scenarios like this:
```
let mut v = Vec::new();
v.push(17);
v.extend(0..10);
println!("{}", v.capacity());
```
`Vec` allocated 22 elements, while it could allocate just 11.
`reserve` function must have a property of keeping `push` operation
cost (which calls `reserve`) `O(1)`. To achieve this `reserve` must
exponentialy grow its capacity when it does reallocation.
There's better strategy to implement `reserve`:
```
let new_capacity = max(current_capacity * 2, requested_capacity);
```
This strategy still guarantees that capacity grows at `O(1)` with
`reserve`, and fixes the issue with `extend`.
bors [Thu, 29 Oct 2015 16:03:46 +0000 (16:03 +0000)]
Auto merge of #29445 - igpay:patch-1, r=alexcrichton
This documentation confused me when trying to use truncate on a project. Originally, it was unclear whether truncate removed the last `len` elements, or whether it cut down the vector to be exactly `len` elements long. The example was also ambiguous.
bors [Thu, 29 Oct 2015 11:14:27 +0000 (11:14 +0000)]
Auto merge of #29188 - nikomatsakis:remove-contraction, r=pnkfelix
This fixes #29048 (though I think adding better transactional support would be a better fix for that issue, but that is more difficult). It also simplifies region inference and changes the model to a pure data flow one, as discussed in [this internals thread](https://internals.rust-lang.org/t/rough-thoughts-on-the-impl-of-region-inference-mir-etc/2800). I am not 100% sure though if this PR is the right thing to do -- or at least maybe not at this moment, so thoughts on that would be appreciated.
bors [Thu, 29 Oct 2015 09:12:26 +0000 (09:12 +0000)]
Auto merge of #29442 - rjbs:docs-comma-splice, r=steveklabnik
This is two sentences that have been comma spliced, and should
be split with a full stop. (This error made me stop and re-read,
and I submit this as an actual improvement to readability, not
as a grammar weird-o!)
bors [Thu, 29 Oct 2015 06:56:52 +0000 (06:56 +0000)]
Auto merge of #29441 - Ryman:match_refactor_msg, r=alexcrichton
This helps for the case where a match, such as below:
```rust
let foo = match foo {
Some(x) => x,
None => 0
};
```
gets refactored to no longer need the match, but the match keyword has been left accidentally:
```rust
let foo = match foo.unwrap_or(0);
```
This can be hard to spot as the expression grows more complex.
Cameron Sun [Thu, 29 Oct 2015 01:38:46 +0000 (21:38 -0400)]
Update docstring for truncate
This documentation confused me when trying to use truncate on a project. Originally, it was unclear whether truncate removed the last `len` elements, or whether it cut down the vector to be exactly `len` elements long. The example was also ambiguous.
Ricardo Signes [Wed, 28 Oct 2015 23:15:20 +0000 (19:15 -0400)]
split a run-on sentence
This is two sentences that have been comma spliced, and should
be split with a full stop. (This error made me stop and re-read,
and I submit this as an actual improvement to readability, not
as a grammar weird-o!)
Steve Klabnik [Thu, 29 Oct 2015 00:27:34 +0000 (20:27 -0400)]
Rollup merge of #29264 - mdinger:colorify, r=steveklabnik
This is an alternative to https://github.com/rust-lang/rust/pull/29240 which fixes #15307 by adding colors to primitives and aliases instead of underlining.
Try to keep the discussion in https://github.com/rust-lang/rust/pull/29240 for now though so it can be kept track of.
A sample rendering is [here](http://mdinger.github.io/rust_std_colored/std/index.html)
Niko Matsakis [Mon, 26 Oct 2015 21:01:36 +0000 (17:01 -0400)]
Don't "double check" var-sub-var constraints, which are handled in
expansion already by growing the RHS to be bigger than LHS (all the way
to `'static` if necessary). This is needed because contraction doesn't
handle givens. Fixes #28934.
Niko Matsakis [Sat, 17 Oct 2015 00:19:25 +0000 (20:19 -0400)]
Remove contraction. The contraction rules predated the notion of an
empty region, and they complicate region inference to no particular end.
They also lead in some cases to spurious errors like #29048 (though in
some cases these errors are helpful in tracking down missing
constraints).
bors [Wed, 28 Oct 2015 11:26:48 +0000 (11:26 +0000)]
Auto merge of #29404 - jonas-schievink:external-overlap-print, r=Aatch
This makes the error message in #28981 a bit shorter (152 to 115 lines).
Previous output (the local impl was always printed twice when it conflicted with an external impl):
```
test.rs:3:1: 3:23 error: conflicting implementations for trait `core::ops::Deref` [E0119]
test.rs:3 impl<T> Deref for T {}
^~~~~~~~~~~~~~~~~~~~~~
test.rs:3:1: 3:23 help: run `rustc --explain E0119` to see a detailed explanation
test.rs:3:1: 3:23 note: conflicting implementation in crate `std`
test.rs:3 impl<T> Deref for T {}
^~~~~~~~~~~~~~~~~~~~~~
```
Output after this patch:
```
test.rs:3:1: 3:23 error: conflicting implementations for trait `core::ops::Deref` [E0119]
test.rs:3 impl<T> Deref for T {}
^~~~~~~~~~~~~~~~~~~~~~
test.rs:3:1: 3:23 help: run `rustc --explain E0119` to see a detailed explanation
note: conflicting implementation in crate `std`
```
bors [Wed, 28 Oct 2015 06:00:19 +0000 (06:00 +0000)]
Auto merge of #29398 - jonas-schievink:if-let-arms, r=arielb1
Closes #29314
The code from #29314:
```rust
fn main() {
if let Some(b) = None {
()
} else {
1
};
}
```
now prints this:
```
test.rs:2:5: 6:6 error: `if let` arms have incompatible types: expected `()`, found `_` (expected (), found integral variable) [E0308]
test.rs:2 if let Some(b) = None {
test.rs:3 ()
test.rs:4 } else {
test.rs:5 1
test.rs:6 };
test.rs:2:5: 6:6 help: run `rustc --explain E0308` to see a detailed explanation
test.rs:4:12: 6:6 note: `if let` arm with an incompatible type
test.rs:4 } else {
test.rs:5 1
test.rs:6 };
error: aborting due to previous error
```
bors [Tue, 27 Oct 2015 22:56:39 +0000 (22:56 +0000)]
Auto merge of #29072 - nagisa:place-arrow, r=pnkfelix
This commit generalises parsing of associative operators from left-associative
only (with some ugly hacks to support right-associative assignment) to properly
left/right-associative operators.
Parsing is still is not general enough to handle non-associative,
non-highest-precedence prefix or non-highest-precedence
postfix operators (e.g. `..` range syntax) and should be made to be.
Lastly, this commit adds support for parsing right-associative `<-` (left arrow)
operator with precedence higher than assignment as the operator for placement-in
feature.
---
This PR still needs various non-parser changes (e.g. src/grammar and tests) and I’m still working on these; the meat of the PR can already be reviewed, though, I think.
Please review carefully. I made sure that quirks I have discovered so far are preserved (see e.g. https://github.com/rust-lang/rust/issues/29071) and am looking for more corner cases as I continue to work on tests et al, but there may be something I haven’t noticed or accounted for.
EDIT: I’m also not sure I managed to preserve all the semantics with the range operator inside non-trivial expressions since these are a mess at the moment. Crater runs would be nice.
bors [Tue, 27 Oct 2015 21:04:59 +0000 (21:04 +0000)]
Auto merge of #28833 - jryans:borrowck-linear-errors, r=pnkfelix
Change error reporting of conflicting loans to stop earlier after printing
an error for a given borrow, instead of proceeding to error on possibly every
issued loan. This keeps us down to O(n) errors (for n problem lines), instead
of O(n^2) errors in some cases.
This commit generalises parsing of associative operators from left-associative
only (with some ugly hacks to support right-associative assignment) to properly
left/right-associative operators.
Parsing still is not general enough to handle non-associative,
non-highest-precedence prefix or non-highest-precedence postfix operators (e.g.
`..` range syntax), though. That should be fixed in the future.
Lastly, this commit adds support for parsing right-associative `<-` (left arrow)
operator with precedence higher than assignment as the operator for placement-in
feature.