Alex Crichton [Tue, 21 Feb 2017 22:18:50 +0000 (14:18 -0800)]
travis: Compile a more compatible libc.a for musl
The mitigations for #34978 involve passing `-Wa,-mrelax-relocations=no` to all C
code we compile, and we just forgot to pass it when compiling musl itself.
bors [Tue, 21 Feb 2017 04:36:46 +0000 (04:36 +0000)]
Auto merge of #39990 - CryZe:emscripten-no-vectorization, r=alexcrichton
Turn off Vectorization for Emscripten
When targeting Emscripten, rustc emits Vector Instructions by default. However Web Assembly doesn't support Vector Instructions yet, which causes Binaryen to fail converting the intermediate asm.js code to Web Assembly. While asm.js kind of supports Vector Instructions, they aren't supported by any browser other than Firefox, often meaning that they need to be emulated very slowly. So it should just be turned off
for all Emscripten targets.
Christopher Serr [Mon, 20 Feb 2017 22:20:06 +0000 (23:20 +0100)]
Turn off Vectorization for Emscripten
When targeting Emscripten, rustc emits Vector Instructions by default.
However Web Assembly doesn't support Vector Instructions yet, which
causes Binaryen to fail converting the intermediate asm.js code to Web
Assembly. While asm.js kind of supports Vector Instructions, they
aren't supported by any browser other than Firefox, often meaning that
they need to be emulated very slowly. So it should just be turned off
for all Emscripten targets.
bors [Mon, 20 Feb 2017 21:31:17 +0000 (21:31 +0000)]
Auto merge of #39717 - pnkfelix:check-timestamps-in-compiletest-miropt, r=alexcrichton
When compiletest'ing src/test/mir-opt, check timestamps.
The tests in src/test/mir-opt embed references to generated files. The names of the generated files embed node id's, which will change depending on the content of the original source.
To guard against comparisons against stale output, check the timestamps of the supposed output against the timestamp of the original source (i.e. any output should be at least as new as the source that was recompiled).
Corey Farwell [Mon, 20 Feb 2017 17:42:55 +0000 (12:42 -0500)]
Rollup merge of #39976 - steveklabnik:reenable-book-linkchecker, r=frewsxcv
Reenable linkchecker for books
In some senses, this is a revert of https://github.com/rust-lang/rust/pull/39633/commits/cacb3bc9c741a7d41a1085af850cd3ff852307f5#diff-b64563d143f859565c8357a28ef81101R212; we disabled linkchecker for the book because the links were added by JavaScript. Now, that's fixed upstream, and so we can re-enable the checker.
This also involves two other fixes: we have to check for `name`s as well as `id`s for links, and the linking algorithm of mdBook changed to the same as rustdoc's, so we change some links back.
~~~This isn't quite ready yet; it's [depending on a PR of mine to mdBook](https://github.com/azerupi/mdBook/pull/209). After that's released, this should be the last of these kinds of shenanigans~~~ 😄
Corey Farwell [Mon, 20 Feb 2017 17:42:53 +0000 (12:42 -0500)]
Rollup merge of #39913 - nikomatsakis:inference-error, r=pnkfelix
Report full details of inference errors
When the old suggestion machinery was removed by @brson in https://github.com/rust-lang/rust/pull/37057, it was not completely removed. There was a bit of code that had the job of going through errors and finding those for which suggestions were applicable, and it remained, causing us not to emit the full details of such errors. This PR removes that.
I've also added various lifetime tests to the UI test suite (so you can also see the before/after there). I have some concrete thoughts on how to improve these cases and am planning on writing those up in some mentoring issues (@CengizIO has expressed interest in working on those changes, so I plan to work with him on it, at least to start).
Steve Klabnik [Mon, 20 Feb 2017 14:30:42 +0000 (09:30 -0500)]
Enable linkchecker on books
Previously, mdBook used JavaScript to add header links, so we
skipped checking the book. As of
https://github.com/rust-lang/rust/pull/39966, it no longer does,
so we can start checking again.
There is a twist, though: it uses name instead of id, so let's test
for both. They're both valid links anyway, so it's good to have the
checker check anyway.
bors [Mon, 20 Feb 2017 15:06:07 +0000 (15:06 +0000)]
Auto merge of #39748 - Rufflewind:master, r=steveklabnik
Rust Book: Generics: Resolving ambiguities
- Add a small section to generics.md to explain how ambiguities in type inference can be resolved using the `::<>` syntax.
- Add links from syntax-index.md and iterators.md.
- Minor edits to iterators.md and structs.md.
The original commit was created because mdBook and rustdoc had
different generation algorithms for header links; now with
https://github.com/rust-lang/rust/pull/39966 , the algorithms
are the same. So let's undo this change.
... when I came across this problem, I said "eh, this isn't fun,
but it doesn't take that long." I probably should have just actually
taken the time to fix upstream, given that they were amenable. Oh
well!
bors [Mon, 20 Feb 2017 03:27:06 +0000 (03:27 +0000)]
Auto merge of #39966 - steveklabnik:update-mdbook, r=GuillaumeGomez
Update mdbook version
This version of mdbook includes
https://github.com/azerupi/mdBook/pull/207 , which is needed so that
we can start doing linkchecker on the various books.
Phil Ruffwind [Sat, 11 Feb 2017 22:00:56 +0000 (17:00 -0500)]
Rust Book: Generics: Resolving ambiguities
- Add a small section to generics.md to explain how ambiguities in type
inference can be resolved using the ::<> syntax.
- Add links from syntax-index.md and iterators.md.
- Minor edits to iterators.md and structs.md.
Steve Klabnik [Sun, 19 Feb 2017 23:55:57 +0000 (18:55 -0500)]
Update mdbook version
This version of mdbook includes
https://github.com/azerupi/mdBook/pull/207 , which is needed so that
we can start doing linkchecker on the various books.
bors [Mon, 20 Feb 2017 00:00:53 +0000 (00:00 +0000)]
Auto merge of #39955 - mp4096:master, r=GuillaumeGomez
Docs: Better explanation of return values for min, max functions for the Iterator trait
Added an explanation that `None` is returned if an iterator is empty.
Also added examples for `max` and `min`. I chose not to add examples for other functions like `max_by_key` etc. so that the examples stay concised and focused on the main functionality.
bors [Sat, 18 Feb 2017 12:17:06 +0000 (12:17 +0000)]
Auto merge of #39887 - nikomatsakis:issue-39292, r=arielb1
erase late bound regions in `get_vtable_methods()`
Higher-ranked object types can otherwise cause late-bound regions to
sneak into the substs, leading to the false conclusion that some method
is unreachable.
r? @arielb1, who wrote the heart of this patch anyhow
bors [Fri, 17 Feb 2017 22:12:00 +0000 (22:12 +0000)]
Auto merge of #39837 - alexcrichton:llvm-crt-static, r=brson
rustc: Link statically to the MSVCRT
This commit changes all MSVC rustc binaries to be compiled with
`-C target-feature=+crt-static` to link statically against the MSVCRT instead of
dynamically (as it does today). This also necessitates compiling LLVM in a
different fashion, ensuring it's compiled with `/MT` instead of `/MD`.
Niko Matsakis [Fri, 17 Feb 2017 15:32:25 +0000 (10:32 -0500)]
add some sample UI error test cases
These are some samples that I have been focusing on improving over
time. In this PR, I mainly want to stem the bleeding where we in some
cases we show an error that gives you no possible way to divine the
problem.
bors [Fri, 17 Feb 2017 07:32:18 +0000 (07:32 +0000)]
Auto merge of #39852 - alexcrichton:appveyor-separate-dist, r=brson
appveyor: Move MSVC dist builds to their own builder
In the long run we want to separate out the dist builders from the test
builders. This provides us leeway to expand the dist builders with more tools
(e.g. Cargo and the RLS) without impacting cycle times.
Currently the Travis dist builders double-up the platforms they provide builds
for, so I figured we could try that out for MSVC as well. This commit adds a new
AppVeyor builder which runs a dist for all the MSVC targets:
If this takes too long and/or times out we'll need to split this up. In any case
we're going to need more capacity from AppVeyor no matter what becaue the two
pc-windows-gnu targets can't cross compile so we need at least 2 more builders
no matter what.
bors [Thu, 16 Feb 2017 20:32:45 +0000 (20:32 +0000)]
Auto merge of #38368 - arthurprs:hm-adapt, r=alexcrichton
Adaptive hashmap implementation
All credits to @pczarn who wrote https://github.com/rust-lang/rfcs/pull/1796 and https://github.com/contain-rs/hashmap2/pull/5
**Background**
Rust std lib hashmap puts a strong emphasis on security, we did some improvements in https://github.com/rust-lang/rust/pull/37470 but in some very specific cases and for non-default hashers it's still vulnerable (see #36481).
This is a simplified version of https://github.com/rust-lang/rfcs/pull/1796 proposal sans switching hashers on the fly and other things that require an RFC process and further decisions. I think this part has great potential by itself.
**Proposal**
This PR adds code checking for extra long probe and shifts lengths (see code comments and https://github.com/rust-lang/rfcs/pull/1796 for details), when those are encountered the hashmap will grow (even if the capacity limit is not reached yet) _greatly_ attenuating the degenerate performance case.
We need a lower bound on the minimum occupancy that may trigger the early resize, otherwise in extreme cases it's possible to turn the CPU attack into a memory attack. The PR code puts that lower bound at half of the max occupancy (defined by ResizePolicy). This reduces the protection (it could potentially be exploited between 0-50% occupancy) but makes it completely safe.
**Drawbacks**
* May interact badly with poor hashers. Maps using those may not use the desired capacity.
* It adds 2-3 branches to the common insert path, luckily those are highly predictable and there's room to shave some in future patches.
* May complicate exposure of ResizePolicy in the future as the constants are a function of the fill factor.
**Example**
Example code that exploit the exposure of iteration order and weak hasher.
Alex Crichton [Wed, 15 Feb 2017 17:36:52 +0000 (09:36 -0800)]
appveyor: Move MSVC dist builds to their own builder
In the long run we want to separate out the dist builders from the test
builders. This provides us leeway to expand the dist builders with more tools
(e.g. Cargo and the RLS) without impacting cycle times.
Currently the Travis dist builders double-up the platforms they provide builds
for, so I figured we could try that out for MSVC as well. This commit adds a new
AppVeyor builder which runs a dist for all the MSVC targets:
If this takes too long and/or times out we'll need to split this up. In any case
we're going to need more capacity from AppVeyor no matter what becaue the two
pc-windows-gnu targets can't cross compile so we need at least 2 more builders
no matter what.
Niko Matsakis [Thu, 16 Feb 2017 18:55:08 +0000 (13:55 -0500)]
erase late bound regions in `get_vtable_methods()`
Higher-ranked object types can otherwise cause late-bound regions to
sneak into the substs, leading to the false conclusion that some method
is unreachable. The heart of this patch is from @arielb1.
bors [Thu, 16 Feb 2017 08:20:29 +0000 (08:20 +0000)]
Auto merge of #39824 - alexcrichton:disable-dist-src, r=brson
travis: Disable source tarballs on most builders
Currently we create a source tarball on almost all of the `DEPLOY=1` builders
but this has the adverse side effect of all source tarballs overriding
themselves in the S3 bucket. Normally this is ok but unfortunately a source
tarball created on Windows is not buildable on Unix.
On Windows the vendored sources contain paths with `\` characters in them which
when interpreted on Unix end up in "file not found" errors.
Instead of this overwriting behavior, whitelist just one linux builder for
producing tarballs and avoid producing tarballs on all other hosts.
Corey Farwell [Thu, 16 Feb 2017 04:48:20 +0000 (23:48 -0500)]
Rollup merge of #39844 - king6cong:sys, r=alexcrichton
sys/mod doc update and mod import order adjust
* Some doc updates.
* Racer currently use the first mod it finds regardless of cfg attrs. Moving #[cfg(unix)] up should be a temporary tweak that works as expected for more people.
Corey Farwell [Thu, 16 Feb 2017 04:48:19 +0000 (23:48 -0500)]
Rollup merge of #39843 - AndrewGaspar:natvis, r=brson
Vec, LinkedList, VecDeque, String, and Option NatVis visualizations
I've added some basic [NatVis](https://msdn.microsoft.com/en-us/library/jj620914.aspx) visualizations for core Rust collections and types. This helps address a need filed in issue #36503. NatVis visualizations are similar to gdb/lldb pretty printers, but for windbg and the Visual Studio debugger on Windows.
For example, Vec without the supplied NatVis looks like this in windbg using the "dx" command:
```
0:000> dx some_64_bit_vec
some_64_bit_vec [Type: collections::vec::Vec<u64>]
[+0x000] buf [Type: alloc::raw_vec::RawVec<u64>]
[+0x010] len : 0x4 [Type: unsigned __int64]
```
With the NatVis, the elements of the Vec are displayed:
```
0:000> dx some_64_bit_vec
some_64_bit_vec : { size=0x4 } [Type: collections::vec::Vec<u64>]
[<Raw View>] [Type: collections::vec::Vec<u64>]
[size] : 0x4 [Type: unsigned __int64]
[capacity] : 0x4 [Type: unsigned __int64]
[0] : 0x4 [Type: unsigned __int64]
[1] : 0x4f [Type: unsigned __int64]
[2] : 0x1a [Type: unsigned __int64]
[3] : 0x184 [Type: unsigned __int64]
```
In fact, the vector can be treated as an array by the NatVis expression evaluator:
```
0:000> dx some_64_bit_vec[2]
some_64_bit_vec[2] : 0x1a [Type: unsigned __int64]
```
In general, it works with any NatVis command that understands collections, such as NatVis LINQ expressions:
```
0:000> dx some_64_bit_vec.Select(x => x * 2)
some_64_bit_vec.Select(x => x * 2)
[0] : 0x8
[1] : 0x9e
[2] : 0x34
[3] : 0x308
```
My biggest concern is the implementation for Option due to the different layouts it can receive based on whether the sentinel value can be embedded with-in the Some value or must be stored separately.
For now all of these visualizations work in windbg, but I've only gotten the visualizations in libcore.natvis working in the VS debugger. My priority is windbg, but somebody else may be interested in investigating the issues related to VS.
You can load these visualizations into a windbg sessions using the .nvload command:
```
0:000> .nvload ..\rust\src\etc\natvis\libcollections.natvis; .nvload ..\rust\src\etc\natvis\libcore.natvis
Successfully loaded visualizers in "..\rust\src\etc\natvis\libcollections.natvis"
Successfully loaded visualizers in "..\rust\src\etc\natvis\libcore.natvis"
```
There are some issues with the symbols that Rust and LLVM conspire to emit into the PDB that inhibit debugging in windbg generally, and by extension make writing visualizations more difficult. Additionally, there are some bugs in windbg itself that complicate or disable some use of the NatVis visualizations for Rust. Significantly, due to NatVis limitations in windbg around allowable type names, you cannot write a visualization for [T] or str. I'll report separate issues as I isolate them.
In the near term, I hope to fill out these NatVis files with more of Rust's core collections and types. In the long run, I hope that we can ship NatVis files with crates and streamline their deployment when debugging Rust programs on windows.
Corey Farwell [Thu, 16 Feb 2017 04:48:13 +0000 (23:48 -0500)]
Rollup merge of #39793 - RalfJung:cell, r=alexcrichton
Allow more Cell methods for non-Copy types
Clearly, `get_mut` is safe for any `T`. The other two only provide unsafe pointers anyway.
The only remaining inherent method with `Copy` bound is `get`, which sounds about right to me.
I found the order if `impl` blocks in the file a little weird (first inherent impl, then some trait impls, then another inherent impl), but didn't change it to keep the diff small.
Corey Farwell [Thu, 16 Feb 2017 04:48:12 +0000 (23:48 -0500)]
Rollup merge of #39775 - mina86:master, r=steveklabnik
book: don’t use GNU extensions in the example unnecessarily
The use of a GNU C extension for bloc expressions is immaterial to the
actual problem with C macros that the section tries to show so don’t
use it and instead use a plain C way of writing the macro which has
added benefit of being better C code (since the macro now behaves like
a function, syntax-wise).
Alex Crichton [Tue, 14 Feb 2017 22:30:39 +0000 (14:30 -0800)]
rustc: Link statically to the MSVCRT
This commit changes all MSVC rustc binaries to be compiled with
`-C target-feature=+crt-static` to link statically against the MSVCRT instead of
dynamically (as it does today). This also necessitates compiling LLVM in a
different fashion, ensuring it's compiled with `/MT` instead of `/MD`.
Alex Crichton [Tue, 14 Feb 2017 17:54:58 +0000 (09:54 -0800)]
travis: Disable source tarballs on most builders
Currently we create a source tarball on almost all of the `DEPLOY=1` builders
but this has the adverse side effect of all source tarballs overriding
themselves in the S3 bucket. Normally this is ok but unfortunately a source
tarball created on Windows is not buildable on Unix.
On Windows the vendored sources contain paths with `\` characters in them which
when interpreted on Unix end up in "file not found" errors.
Instead of this overwriting behavior, whitelist just one linux builder for
producing tarballs and avoid producing tarballs on all other hosts.
bors [Wed, 15 Feb 2017 22:02:36 +0000 (22:02 +0000)]
Auto merge of #39457 - bvinc:master, r=alexcrichton
Dont segfault if btree range is not in order
This is a first attempt to fix issue #33197. The issue is that the BTree iterator uses next_unchecked for fast iteration, but it can be tricked into running off the end of the tree and segfaulting if range is called with a maximum that is less than the minimum.
Since a user defined Ord should not determine the safety of BTreeMap, and we still want fast iteration, I've implemented the idea of @gereeter and walk the tree simultaneously searching for both keys to make sure that if our keys diverge, the min key is to the left of our max key. I currently panic if that is not the case.
Open questions:
1. Do we want to panic in this error case or do we want to return an empty iterator? The drain API panics if the range is bad, but drain is given a range of index values, while this is a generic key type. Panicking is brittle and returning an empty iterator is probably the most flexible and matches what people would want it to do... but artificially returning a BTreeMap::Range with start==end seems like a pretty weird and unnatural thing to do, although it's doable since those fields are not accessible.
The same question for other weird cases:
2. (Included(101), Excluded(100)) on a map that contains [1,2,3]. Both BTree edges end up on the same part of the map, but comparing the keys shows the range is backwards.
3. (Excluded(5), Excluded(5)). The keys are equal but BTree edges end up backwards if the map contains 5.
4. (Included(5), Excluded(5)). Should naturally produce an empty iterator, right?
book: don’t use GNU extensions in the example unnecessarily
The use of a GNU C extension for bloc expressions is immaterial to the
actual problem with C macros that the section tries to show so don’t
use it and instead use a plain C way of writing the macro.
bors [Wed, 15 Feb 2017 10:22:34 +0000 (10:22 +0000)]
Auto merge of #39594 - clarcharr:cstr_box, r=aturon
Conversions between CStr, OsStr, Path and boxes
This closes a bit of the inconsistencies between `CStr`, `OsStr`, `Path`, and `str`, allowing people to create boxed versions of DSTs other than `str` and `[T]`.
Full list of additions:
* `Default` for `Box<str>`, `Box<CStr>`, `Box<OsStr>`, and `Box<Path>` (note: `Default` for `PathBuf` is already implemented)
* `CString::into_boxed_c_str` (feature gated)
* `OsString::into_boxed_os_str` (feature gated)
* `Path::into_boxed_path` (feature gated)
* `From<&CStr> for Box<CStr>`
* `From<&OsStr> for Box<OsStr>`
* `From<&Path> for Box<Path>`
This also includes adding the internal methods:
* `sys::*::os_str::Buf::into_box`
* `sys::*::os_str::Slice::{into_box, empty_box}`
* `sys_common::wtf8::Wtf8Buf::into_box`
* `sys_common::wtf8::Wtf8::{into_box, empty_box}`
projects / rust.git / log