bors [Wed, 10 Feb 2016 14:24:41 +0000 (14:24 +0000)]
Auto merge of #31499 - kamalmarhubi:cfg-flag-invalid-cfgs, r=brson
A spec like `#[cfg(foo(bar))]` is not allowed as an attribute. This
makes the same spec be rejected by the compiler if passed in as a
`--cfg` argument.
bors [Wed, 10 Feb 2016 10:04:46 +0000 (10:04 +0000)]
Auto merge of #31420 - bluss:deque-equality, r=Gankro
collections: Use slice parts in PartialEq for VecDeque
This improves == for VecDeque by using the slice representation.
This will also improve further if codegen for slice comparison improves.
Benchmark run of 1000 u64 elements, comparing for equality (all equal).
Cpu time to compare the vecdeques is reduced to less than 50% of what it
was before.
bors [Wed, 10 Feb 2016 08:03:06 +0000 (08:03 +0000)]
Auto merge of #31494 - alexcrichton:ar-gnu-by-default, r=brson
The compiler currently vendors its own version of "llvm-ar" (not literally the
binary but rather the library support) and uses it for all major targets by
default (e.g. everything defined in `src/librustc_back/target`). All custom
target specs, however, still search for an `ar` tool by default. This commit
changes this default behavior to using the internally bundled llvm-ar with the
GNU format.
Currently all targets use the GNU format except for OSX which uses the BSD
format (surely makes sense, right?), and custom targets can change the format
via the `archive-format` key in custom target specs.
I suspect that we can outright remove support for invoking an external `ar`
utility, but I figure for now there may be some crazy target relying on that so
we should leave support in for now.
bors [Wed, 10 Feb 2016 01:05:42 +0000 (01:05 +0000)]
Auto merge of #31438 - aturon:stab-ip-addr, r=alexcrichton
After [considerable pushback](https://github.com/rust-lang/rfcs/issues/1451), it's clear that there is a community consensus around providing `IpAddr` in the standard library, together with other APIs using it.
This commit reverts from deprecated status directly to stable. The deprecation landed in 1.6, which has already been released, so the stabilization is marked for 1.7 (currently in beta; will require a backport).
Aaron Turon [Sat, 6 Feb 2016 00:22:45 +0000 (16:22 -0800)]
Revert deprecation of IpAddr, stabilizing for 1.7
After [considerable
pushback](https://github.com/rust-lang/rfcs/issues/1451), it's clear
that there is a community consensus around providing `IpAddr` in the
standard library, together with other APIs using it.
This commit reverts from deprecated status directly to stable. The
deprecation landed in 1.6, which has already been released, so the
stabilization is marked for 1.7 (currently in beta; will require a backport).
bors [Tue, 9 Feb 2016 15:14:25 +0000 (15:14 +0000)]
Auto merge of #31510 - dikaiosune:master, r=bluss
Since a lexicographic ordering of a struct could vary based on which struct members are compared first, I ended up doing some testing to ensure that the behavior when deriving these traits was what I expected (ordered based on the top to bottom order of declaration of the members). I wanted to add this little bit of documentation to potentially save someone else the same effort. That is, assuming that my testing correctly reflects the intended behavior of the compiler.
bors [Tue, 9 Feb 2016 04:27:42 +0000 (04:27 +0000)]
Auto merge of #31489 - ben0x539:lock-to-guard, r=alexcrichton
The comment in the next line was already talking about `_guard`, and the scope guard a couple lines further down is also called `guard`, so I assume that was just a typo.
bors [Tue, 9 Feb 2016 02:27:58 +0000 (02:27 +0000)]
Auto merge of #31500 - steveklabnik:fix_cow, r=alexcrichton
When I last did a pass through the string documentation, I focused on
consistency across similar functions. Unfortunately, I missed some
details. This example was _too_ consistent: it wasn't actually accurate!
This commit fixes the docs do both be more accurate and to explain why
the return type is a Cow<'a, str>.
First reported here:
https://www.reddit.com/r/rust/comments/44q9ms/stringfrom_utf8_lossy_doesnt_return_a_string/
bors [Tue, 9 Feb 2016 00:19:45 +0000 (00:19 +0000)]
Auto merge of #31278 - alexcrichton:print-cfg, r=brson
This commit is an implementation of the new compiler flags required by [RFC
1361][rfc]. This specifically adds a new `cfg` option to the `--print` flag to
the compiler. This new directive will print the defined `#[cfg]` directives by
the compiler for the target in question.
Alex Crichton [Mon, 25 Jan 2016 19:36:18 +0000 (11:36 -0800)]
rustc: Implement a new `--print cfg` flag
This commit is an implementation of the new compiler flags required by [RFC
1361][rfc]. This specifically adds a new `cfg` option to the `--print` flag to
the compiler. This new directive will print the defined `#[cfg]` directives by
the compiler for the target in question.
bors [Mon, 8 Feb 2016 22:19:41 +0000 (22:19 +0000)]
Auto merge of #31397 - bradfirj:arc-docfix, r=steveklabnik
The documentation for the `make_mut` function on `Arc<T>` contains a somewhat impenetrable double-negative that I was only able to fully grasp by looking at the implementation. Here's a quick rewrite that reads a lot better.
The sentence "doesn't have one strong reference and no weak references." is a
hard to understand, and it can be much more easily explained. In particular, such a double-negative
could give English as a Second Language users even more trouble than native speakers.
Kamal Marhubi [Mon, 8 Feb 2016 21:38:35 +0000 (16:38 -0500)]
driver: Disallow predicates in --cfg specs
A spec like `#[cfg(foo(bar))]` is not allowed as an attribute. This
makes the same spec be rejected by the compiler if passed in as a
`--cfg` argument.
Steve Klabnik [Mon, 8 Feb 2016 22:10:55 +0000 (17:10 -0500)]
Fix up docs for String::from_utf8_lossy()
When I last did a pass through the string documentation, I focused on
consistency across similar functions. Unfortunately, I missed some
details. This example was _too_ consistent: it wasn't actually accurate!
This commit fixes the docs do both be more accurate and to explain why
the return type is a Cow<'a, str>.
First reported here:
https://www.reddit.com/r/rust/comments/44q9ms/stringfrom_utf8_lossy_doesnt_return_a_string/
Piotr Czarnecki [Mon, 8 Feb 2016 22:08:47 +0000 (23:08 +0100)]
Cleanup based on review by @nagisa
* We don't have SEH-based unwinding yet.
For this reason we don't need operand bundles in MIR trans.
* Refactored some uses of fcx.
* Refactored some calls to `with_block`.
Tomasz Miąsko [Sat, 6 Feb 2016 17:42:17 +0000 (18:42 +0100)]
Breaking tokens into pieces should behave similar to Parser::bump.
Previously when breaking tokens into smaller pieces, the replace_token
function have been used. It replaced current token and updated span
information, but it did not clear the list of expected tokens, neither
did it update remaining info about last token. This could lead to
incorrect error message, like one described in the issue #24780:
Kamal Marhubi [Sun, 7 Feb 2016 22:57:01 +0000 (17:57 -0500)]
Implement fmt::Pointer for pointers to unsized types
This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
- impl<'a, T: ?Sized> Pointer for &'a T
- impl<'a, T: ?Sized> Pointer for &'a mut T
- impl<T: ?Sized> Pointer for *const T
- impl<T: ?Sized> Pointer for *mut T
- impl<T: ?Sized> fmt::Pointer for Box<T>
- impl<T: ?Sized> fmt::Pointer for Rc<T>
- impl<T: ?Sized> fmt::Pointer for Arc<T>
bors [Mon, 8 Feb 2016 19:04:25 +0000 (19:04 +0000)]
Auto merge of #31324 - nagisa:mir-transforms, r=nikomatsakis
Having a `MirPass` provides literally no benefits over `MutVisitor`. Moreover using `MirPass` for
`EraseRegions` basically makes the programmer to fix breakage from changing repr twice – in the
visitor and eraseregions. Since `MutVisitor` implements all the “walking” inside the trait, that can
be reused for `EraseRegions` too, basically resulting in less code duplication.
Alex Crichton [Mon, 8 Feb 2016 18:27:03 +0000 (10:27 -0800)]
rustc: Use llvm-ar for custom targets by default
The compiler currently vendors its own version of "llvm-ar" (not literally the
binary but rather the library support) and uses it for all major targets by
default (e.g. everything defined in `src/librustc_back/target`). All custom
target specs, however, still search for an `ar` tool by default. This commit
changes this default behavior to using the internally bundled llvm-ar with the
GNU format.
Currently all targets use the GNU format except for OSX which uses the BSD
format (surely makes sense, right?), and custom targets can change the format
via the `archive-format` key in custom target specs.
I suspect that we can outright remove support for invoking an external `ar`
utility, but I figure for now there may be some crazy target relying on that so
we should leave support in for now.
Benjamin Herr [Mon, 8 Feb 2016 13:48:12 +0000 (14:48 +0100)]
std: `_lock` -> `_guard` in Mutex example
The comment in the next line was already talking about `_guard`, and the
scope guard a couple lines further down is also called `guard`, so I
assume that was just a typo.
Split dummy in region inference graph into distinct source and sink nodes.
Why do this: The RegionGraph representation previously conflated all
of the non-variable regions (i.e. the concrete regions such as
lifetime parameters to the current function) into a single dummy node.
A single dummy node leads DFS on a graph `'a -> '_#1 -> '_#0 -> 'b` to
claim that `'_#1` is reachable from `'_#0` (due to `'a` and `'b` being
conflated in the graph representation), which is incorrect (and can
lead to soundness bugs later on in compilation, see #30438).
Splitting the dummy node ensures that DFS will never introduce new
ancestor relationships between nodes for variable regions in the
graph.
bors [Sun, 7 Feb 2016 23:31:46 +0000 (23:31 +0000)]
Auto merge of #31470 - alexcrichton:lets-find-jemalloc, r=brson
Both of these targets have jemalloc disabled unconditionally right now, so using
`maybe_jemalloc` here isn't right. This fixes the case where a Linux compiler
(which is itself configured to use jemalloc) attempts to cross-compile to MinGW,
causing it to try to find an `alloc_jemalloc` crate (and failing).
Alex Crichton [Sun, 7 Feb 2016 20:03:06 +0000 (12:03 -0800)]
rustc: Tweak exe allocator for MinGW/rumprun
Both of these targets have jemalloc disabled unconditionally right now, so using
`maybe_jemalloc` here isn't right. This fixes the case where a Linux compiler
(which is itself configured to use jemalloc) attempts to cross-compile to MinGW,
causing it to try to find an `alloc_jemalloc` crate (and failing).
bors [Sun, 7 Feb 2016 00:16:58 +0000 (00:16 +0000)]
Auto merge of #31440 - reem:rwlock-map-fix, r=alexcrichton
Also update the instability reason to include a note about a possible
bad interaction with condition variables on systems that allow
waiting on a RwLock guard.
bors [Sat, 6 Feb 2016 21:18:50 +0000 (21:18 +0000)]
Auto merge of #30629 - brson:emscripten-upstream, r=alexcrichton
Here's another go at adding emscripten support. This needs to wait again on new [libc definitions](https://github.com/rust-lang-nursery/libc/pull/122) landing. To get the libc definitions right I had to add support for i686-unknown-linux-musl, which are very similar to emscripten's, which are derived from arm/musl.
This branch additionally removes the makefile dependency on the `EMSCRIPTEN` environment variable by not building the unused compiler-rt.
Again, this is not sufficient for actually compiling to asmjs since it needs additional LLVM patches.
bors [Sat, 6 Feb 2016 19:16:10 +0000 (19:16 +0000)]
Auto merge of #31428 - reem:remove-mutexguard-map, r=alexcrichton
It could return in the future if it returned a different guard type, which
could not be used with Condvar, otherwise it is unsafe as another thread
can invalidate an "inner" reference during a Condvar::wait.