bors [Wed, 4 Nov 2015 02:13:05 +0000 (02:13 +0000)]
Auto merge of #29217 - nikomatsakis:mir-trans, r=dotdash
This branch implements a variant of trans that is based on MIR. It is very incomplete (intentionally), and had only the goal of laying out enough work to enable more incremental follow-on patches. Currently, only fns tagged with `#[rustc_mir]` use the new trans code. I plan to build up a meta-issue as well that tracks the various "not-yet-implemented" points. The only fn that has been tested so far is this amazingly complex "spike" fn:
```rust
#[rustc_mir]
fn sum(x: i32, y: i32) -> i32 {
x + y
}
```
In general, the most interesting commit is the last one. There are some points on which I would like feedback from @rust-lang/compiler:
- I did not use `Datum`. Originally, I thought that maybe just a `ValueRef` would be enough but I wound up with two very simple structures, `LvalueRef` and `OperandRef`, that just package up a `ValueRef` and a type. Because of MIR's structure, you don't wind up mixing by-ref and by-value so much, and I tend to think that a thinner abstraction layer is better here, but I'm not sure.
- Related to the above, I expect that sooner or later we will analyze temps (and maybe variables too) to find those whose address is never taken and which are word-sized and which perhaps meet a few other criteria. For those, we'll probably want to avoid the alloca, just because it means prettier code.
- I generally tried to re-use data structures from elsewhere in trans, though I'm sure we can trim these down.
- I didn't do any debuginfo primarily because it seems to want node-ids and we have only spans. I haven't really read into that code so I don't know what's going on there.
bors [Wed, 4 Nov 2015 00:30:05 +0000 (00:30 +0000)]
Auto merge of #29547 - arielb1:speculative-upvar, r=eddyb
`resolve_identifier` used to mark a variable as an upvar when used within a closure. However, the function is also used for the "unnecessary qualification" lint, which would mark paths whose last component had the same name as a local as upvars.
bors [Tue, 3 Nov 2015 17:02:13 +0000 (17:02 +0000)]
Auto merge of #29529 - Ryman:rustdoc-cap-lints, r=alexcrichton
This sets the `cap-lints` setting to 'allow' for all doc compilations. There's precedent for this as rustdoc [already whitelists unstable code](https://github.com/rust-lang/rust/blob/master/src/librustdoc/core.rs#L112) when compiling documentation, with the expectation being that a regular compile will complain about any problems. I think the same justification applies here.
Problem case in the wild: https://github.com/laumann/compiletest-rs/pull/28
bors [Tue, 3 Nov 2015 13:34:09 +0000 (13:34 +0000)]
Auto merge of #29495 - meqif:fix_unindent_tabs, r=steveklabnik
A line may be indented with either spaces or tabs, but not a mix of both. If there is a mix of tabs and spaces, only the kind that occurs first is counted.
bors [Tue, 3 Nov 2015 06:34:53 +0000 (06:34 +0000)]
Auto merge of #29523 - durka:patch-9, r=alexcrichton
`Rc::try_unwrap` and `Rc::make_mut` are stable since 1.4.0, but the example code still has `#![feature(rc_unique)]`. Ideally the stable and beta docs would be updated, but I don't think that's possible :(
bors [Tue, 3 Nov 2015 01:23:10 +0000 (01:23 +0000)]
Auto merge of #29500 - vadimcn:rustlib, r=alexcrichton
According to a recent [discussion on IRC](https://botbot.me/mozilla/rust-tools/2015-10-27/?msg=52887517&page=2), there's no good reason for Windows builds to store target libraries under `bin`, when on every other platform they are under `lib`.
This might be a [breaking-change] for some users. I am pretty sure VisualRust has that path hard-coded somewhere.
bors [Mon, 2 Nov 2015 23:38:49 +0000 (23:38 +0000)]
Auto merge of #29291 - petrochenkov:privacy, r=alexcrichton
The public set is expanded with trait items, impls and their items, foreign items, exported macros, variant fields, i.e. all the missing parts. Now it's a subset of the exported set.
This is needed for https://github.com/rust-lang/rust/pull/29083 because stability annotation pass uses the public set and all things listed above need to be annotated.
Rustdoc can now be migrated to the public set as well, I guess.
Exported set is now slightly more correct with regard to exported items in blocks - 1) blocks in foreign items are considered and 2) publicity is not inherited from the block's parent - if a function is public it doesn't mean structures defined in its body are public.
bors [Mon, 2 Nov 2015 21:56:47 +0000 (21:56 +0000)]
Auto merge of #29456 - alexcrichton:path-hash, r=aturon
Almost all operations on Path are based on the components iterator in one form
or another to handle equivalent paths. The `Hash` implementations, however,
mistakenly just went straight to the underlying `OsStr`, causing these
equivalent paths to not get merged together.
This commit updates the `Hash` implementation to also be based on the iterator
which should ensure that if two paths are equal they hash to the same thing.
Alex Crichton [Thu, 29 Oct 2015 17:56:54 +0000 (10:56 -0700)]
std: Base Hash for Path on its iterator
Almost all operations on Path are based on the components iterator in one form
or another to handle equivalent paths. The `Hash` implementations, however,
mistakenly just went straight to the underlying `OsStr`, causing these
equivalent paths to not get merged together.
This commit updates the `Hash` implementation to also be based on the iterator
which should ensure that if two paths are equal they hash to the same thing.
Alex Burka [Mon, 2 Nov 2015 20:36:22 +0000 (15:36 -0500)]
remove #![feature(rc_unique)] from Rc docs
`Rc::try_unwrap` and `Rc::make_mut` are stable since 1.4.0, but the example code still has `#![feature(rc_unique)]`. Ideally the stable and beta docs would be updated, but I don't think that's possible...
bors [Mon, 2 Nov 2015 08:01:56 +0000 (08:01 +0000)]
Auto merge of #29505 - rjbs:docs-where-type, r=steveklabnik
I read this section a few times before even having a guess what
was meant, then consulted IRC for confirmation. It may be that I
was thick-headed, but I think this is a useful addition.
Ricardo Signes [Sun, 1 Nov 2015 18:28:51 +0000 (13:28 -0500)]
Attempt to clarify use of `where i32: ConvertTo<T>
I read this section a few times before even having a guess what
was meant, then consulted IRC for confirmation. It may be that I
was thick-headed, but I think this is a useful addition.
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`.