Corey Farwell [Fri, 24 Mar 2017 23:13:12 +0000 (18:13 -0500)]
Rollup merge of #40739 - cuviper:hash-rev-drop, r=arthurprs
Simplify hash table drops
This replaces the `std::collections::hash::table::RevMoveBuckets`
iterator with a simpler `while` loop. This iterator was only used for
dropping the remaining elements of a `RawTable`, so instead we can just
loop through directly and drop them in place.
This should be functionally equivalent to the former code, but a little
easier to read. I was hoping it might have some performance benefit
too, but it seems the optimizer was already good enough to see through
the iterator -- the generated code is nearly the same. Maybe it will
still help if an element type has more complicated drop code.
Corey Farwell [Fri, 24 Mar 2017 23:13:11 +0000 (18:13 -0500)]
Rollup merge of #40636 - nikomatsakis:revert-39485, r=eddyb
Revert #39485, fixing type-inference regressions
This reverts PR #39485, which should fix the immediate regressions. Eventually I'd like to land https://github.com/rust-lang/rust/pull/40224 -- or some variant of it -- which revisits the question fo dead-code and inference.
Corey Farwell [Fri, 24 Mar 2017 23:13:09 +0000 (18:13 -0500)]
Rollup merge of #40567 - clarcharr:rustdoc-sort, r=frewsxcv
Fix for #39596: sort Trait2 before Trait10.
This is a change discussed in #39596. Essentially, item names will be sorted as if they're (&str, u64) pairs instead of just `&str`, meaning that `"Apple" < "Banana"` and also `"Fruit10" > "Fruit2"`.
bors [Fri, 24 Mar 2017 18:40:57 +0000 (18:40 +0000)]
Auto merge of #40777 - alexcrichton:update-mingw-compilers, r=aturon
appveyor: Upgrade MinGW toolchains we use
In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.
When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.
I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.
Alex Crichton [Thu, 23 Mar 2017 22:46:40 +0000 (15:46 -0700)]
appveyor: Upgrade MinGW toolchains we use
In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.
When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.
I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.
bors [Fri, 24 Mar 2017 15:42:15 +0000 (15:42 +0000)]
Auto merge of #40769 - alexcrichton:osx-crash-logs, r=nikomatsakis
travis: See if OSX generates crash dumps
I know for a fact we've had sccache segfault on various platforms and we've also
historically had a lot of problems with the linker on OSX. Let's just poke
around in the crash log directory to see if anything exists. If in the future we
see a build we think segfaulted *and* there's contents here then we can add some
bits that actually print out the logs.
Alex Crichton [Thu, 23 Mar 2017 19:33:24 +0000 (12:33 -0700)]
travis: Attempt to see if oom kills anything
There's a suspicion that the OOM killer is killing sccache (maybe) so this adds
some logging to test out that assumption to see if anything dies and is logged
by `dmesg`
Alex Crichton [Thu, 23 Mar 2017 19:00:50 +0000 (12:00 -0700)]
travis: See if OSX generates crash dumps
I know for a fact we've had sccache segfault on various platforms and we've also
historically had a lot of problems with the linker on OSX. Let's just poke
around in the crash log directory to see if anything exists. If in the future we
see a build we think segfaulted *and* there's contents here then we can add some
bits that actually print out the logs.
bors [Thu, 23 Mar 2017 18:43:40 +0000 (18:43 +0000)]
Auto merge of #40759 - alexcrichton:appveyor-retry, r=brson
appveyor: Leverage auto-retry to upload to S3
This was recently implemented (appveyor/ci#1387) in response to one of our
feature requests, so let's take advantage of it! I'm going to optimistically
say...
Alex Crichton [Wed, 22 Mar 2017 18:33:07 +0000 (11:33 -0700)]
travis: Delay sccache downloads in docker
Let's have this layer be towards the end as we're emprically changing sccache
more than we're changing the rest of the image, so this'll allow us to reuse as
much of the cached image as possible.
Alex Crichton [Thu, 23 Mar 2017 14:07:02 +0000 (07:07 -0700)]
appveyor: Leverage auto-retry to upload to S3
This was recently implemented (appveyor/ci#1387) in response to one of our
feature requests, so let's take advantage of it! I'm going to optimistically
say...
Corey Farwell [Thu, 23 Mar 2017 13:42:49 +0000 (08:42 -0500)]
Rollup merge of #40753 - mandeep:change-ObjectSafetyViolation-message, r=brson
Change object safety violation message
Hello!
This is my first pull request to rust so hopefully all goes well. This PR should fix issue #40670. I changed the error message in object_safety.rs and the corresponding compile-fail test in object-safety-supertrait-mentions-Self.rs.
Once the changes were made, I ran ```python x.py test src/tools/tidy``` and ```python x.py test```. Tidy passed and the compile-fail tests passed, however the test suite failed on the tcp tests as my machine has IPv6 disabled. I'm not sure what to do in this case besides letting travis run the suite against my changes. Please let me know if there's anything I can do to help further.
Corey Farwell [Thu, 23 Mar 2017 13:42:48 +0000 (08:42 -0500)]
Rollup merge of #40715 - manuel-rhdt:patch-1, r=brson
Fix doc error for ExactSizeIterator
The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.
This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.
Corey Farwell [Thu, 23 Mar 2017 13:42:46 +0000 (08:42 -0500)]
Rollup merge of #40627 - estebank:pub-restricted, r=petrochenkov
Add diagnostic for incorrect `pub (restriction)`
Given the following statement
```rust
pub (a) fn afn() {}
```
Provide the following diagnostic:
```rust
error: incorrect restriction in `pub`
--> file.rs:15:1
|
15 | pub (a) fn afn() {}
| ^^^
|
= help: some valid visibility restrictions are:
`pub(crate)`: visible only on the current crate
`pub(super)`: visible only in the current module's parent
`pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
| pub (in a) fn afn() {}
```
Corey Farwell [Thu, 23 Mar 2017 13:42:45 +0000 (08:42 -0500)]
Rollup merge of #40612 - TimNN:new-netbsd-cross, r=alexcrichton
Use the "official" cross compiler for NetBSD
The current NetBSD cross compiler is lacking, for example `std::thread` is not available (which causes problems for LLVM 4.0). This PR uses the official netbsd build system to compiler the cross compiler.
@alexcrichton: Can you please mirror `ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/source/sets/{src,gnusrc,sharesrc,syssrc}.tgz`. (Optionally you may want to use NetBSD versions 7.0.2 or 7.1, in that case you'll probably want to update the binary downloads used today as well).
I'll update the URL's afterwards (or feel free to use "allow edits from maintainers").
bors [Thu, 23 Mar 2017 12:03:39 +0000 (12:03 +0000)]
Auto merge of #40605 - alexcrichton:add-stamps, r=brson
travis: Add timestamps to all build messages
When debugging why builds are taking so long it's often useful to get the
timestamp of all log messages as we're not always timing every tiny step of the
build. I wrote a [utility] for prepending a relative timestamp from the start of
a process which is now downloaded to the builders and is what we wrap the entire
build invocation in.
bors [Thu, 23 Mar 2017 09:18:11 +0000 (09:18 +0000)]
Auto merge of #40549 - alexcrichton:uwtable-everywhere, r=eddyb
rustc: Always emit the `uwtable` attribute on Windows
This commit alters the translation layer to unconditionally emit the `uwtable`
LLVM attribute on Windows regardless of the `no_landing_pads` setting.
Previously I believe we omitted this attribute as an optimization when the
`-Cpanic=abort` flag was passed, but this unfortunately caused problems for
Gecko.
It [was discovered] that there was trouble unwinding through Rust functions due
to foreign exceptions such as illegal instructions or otherwise in-practice
methods used to abort a process. In testing it looked like the major difference
between a working binary and a non-working binary is indeed this `uwtable`
attribute, but this PR has unfortunately not been thoroughly tested in terms of
compiling Gecko with `-C panic=abort` *and* this PR to see whether it works, so
this is still somewhat working on just suspicion.
bors [Thu, 23 Mar 2017 06:48:23 +0000 (06:48 +0000)]
Auto merge of #40515 - alexcrichton:tarball-names, r=brson
rustbuild: Don't hardcode 'nightly' for Cargo
It now follows rustc release trains. I also had to land this commit on beta (https://github.com/rust-lang/rust/commit/0a27a8713bdca09564ffd298fce8f760e47775af) before https://github.com/rust-lang/rust/pull/40484 could land, so this is basically just a forward port (if you will) of that commit to master.
Esteban Küber [Sat, 18 Mar 2017 04:13:00 +0000 (21:13 -0700)]
Add diagnostic for incorrect `pub (restriction)`
Given the following statement
```rust
pub (a) fn afn() {}
```
Provide the following diagnostic:
```rust
error: incorrect restriction in `pub`
--> file.rs:15:1
|
15 | pub (a) fn afn() {}
| ^^^^^^^
|
= help: some valid visibility restrictions are:
`pub(crate)`: visible only on the current crate
`pub(super)`: visible only in the current module's parent
`pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
| pub (in a) fn afn() {}
```
Corey Farwell [Thu, 23 Mar 2017 03:38:03 +0000 (23:38 -0400)]
Rollup merge of #40696 - cramertj:remove-unused-adt-def-code, r=petrochenkov
Remove unused adt-def insertion by constructor DefIndex
It looks to me like ADT definitions weren't being looked up by constructor id, and a test run supports my theory.
In any case, I'm not sure it would have worked in its current configuration. If I understand correctly, the `adt_def` map entry from constructor id -> adt def would only be present after a successful call to `queries::adt_def::get` with the proper ADT `DefIndex`. Trying to look up an adt_def by the constructor index prior to a successful lookup by ADT index would fail since `item.kind` would be `EntryKind::Fn` (for the constructor function) and so would trigger the `bug!`.
Corey Farwell [Thu, 23 Mar 2017 03:38:02 +0000 (23:38 -0400)]
Rollup merge of #40678 - michaelwoerister:dmi-prep, r=nikomatsakis
Some preparations for directly computing the ICH of crate-metadata.
This PR contains some small fixes in preparation for direct metadata hashing. It mostly just moves stuff into places where it will be needed (making the module structure slightly cleaner along the way) and it fixes some omissions in the MIR region eraser.
Corey Farwell [Thu, 23 Mar 2017 03:38:00 +0000 (23:38 -0400)]
Rollup merge of #40542 - abonander:issue_40535, r=jseyfried
Correctly get source for metatdata-only crate type
Closes #40535
However, I'm not sure how to approach writing a regression test since I'm still working on a reduced test case from the code that caused the ICE in the first place. It's not enough to have an unknown `extern crate` in a metadata crate, it depends on a few extra arguments but I'm not sure which yet.
Also replaced the `unwrap()` with a more informative `expect()`.
Corey Farwell [Thu, 23 Mar 2017 03:37:59 +0000 (23:37 -0400)]
Rollup merge of #40518 - michaelwoerister:hir-id, r=eddyb
Introduce HirId, a replacement for ast::NodeId after lowering to HIR
This is the first step towards implementing #40303. This PR introduces the `HirId` type and generates a `HirId` for everything that would be assigned one (i.e. stuff in the HIR), but the HIR data types still use `NodeId` for now. Changing that is a big refactoring that I want to do in a separate PR.
A `HirId` uniquely identifies a node in the HIR of the current crate. It is composed of the `owner`, which is the `DefIndex` of the directly enclosing `hir::Item`, `hir::TraitItem`, or `hir::ImplItem` (i.e. the closest "item-like"), and the `local_id` which is unique within the given owner.
This PR is also running a number of consistency checks for the generated `HirId`s:
- Does `NodeId` in the HIR have a corresponding `HirId`?
- Is the `owner` part of each `HirId` consistent with its position in the HIR?
- Do the numerical values of the `local_id` part all lie within a dense range of integers?
Corey Farwell [Thu, 23 Mar 2017 03:37:58 +0000 (23:37 -0400)]
Rollup merge of #39891 - shepmaster:emit-mir, r=nikomatsakis
Teach rustc --emit=mir
I'm opening this PR to discuss:
1. Is this a good idea?
1. Is this a good implementation?
I'm sure people will have opinions on both points!
This spawned from https://github.com/rust-lang/rust/issues/31847#issuecomment-279179057, so I figured a prototype implementation could help provide a seed to talk about.
Corey Farwell [Wed, 22 Mar 2017 23:30:35 +0000 (19:30 -0400)]
Rollup merge of #40732 - petrochenkov:booktidy, r=steveklabnik
Update the book submodule and fix tidy
When the book was included into https://github.com/rust-lang/rust as a submodule, tidy started failing on Windows.
https://github.com/rust-lang/book/pull/549 fixed the problem, now the submodule needs to be updated.
Corey Farwell [Wed, 22 Mar 2017 23:30:31 +0000 (19:30 -0400)]
Rollup merge of #40704 - omtcyfz:clang_version_bump, r=alexcrichton
Nit: LLVM & Clang latest version is 4.0
Small nit: since latest Clang version is 4.0 it's nice to reflect this in the documentation.
Also, I couldn't find anything, but there might be any hard-coded check that Clang version matches "3.X" anywhere in the build system; if there is one, it'd be great to bump that one too.
Corey Farwell [Wed, 22 Mar 2017 23:30:30 +0000 (19:30 -0400)]
Rollup merge of #40692 - SamWhited:consistent_str_docs_punctuation, r=bstrie
str: Make docs consistently punctuated
Every so slightly pointless one character PR, but this was driving me nuts while reading the docs a moment ago (all the [other public structs](https://doc.rust-lang.org/std/str/index.html#structs) have descriptions that end in a full-stop).
Corey Farwell [Wed, 22 Mar 2017 23:30:26 +0000 (19:30 -0400)]
Rollup merge of #40578 - michaelwoerister:shorter-compiletest-stamps, r=alexcrichton
Make the filenames of .stamp files generated by compiletest shorter
Otherwise we run into filename length limitations on some file systems. See https://bugs.launchpad.net/ecryptfs/+bug/344878 for an example where we only can have ~145 characters for filenames.
Corey Farwell [Wed, 22 Mar 2017 23:30:25 +0000 (19:30 -0400)]
Rollup merge of #40548 - alexcrichton:appveyor-ninja, r=brson
appveyor: Use Ninja to build LLVM on MinGW
I have a suspicion that MinGW's make is the cause of #40546 rather than anything
else, but that's purely a suspicion without any facts to back it up. In any case
we'll eventually be moving the MSVC build over to Ninja in order to leverage
sccache regardless, so this commit simply jumpstarts that process by downloading
Ninja for use by MinGW anyway.
I'm not sure if this closes #40546 for real, but this is my current best shot at
closing it out, so...
Corey Farwell [Wed, 22 Mar 2017 23:30:23 +0000 (19:30 -0400)]
Rollup merge of #40509 - jseyfried:duplicate_check_macro_exports, r=nrc
Forbid conflicts between macros 1.0 exports and macros 2.0 exports
This PR forbids for conflicts between `#[macro_export]`/`#[macro_reexport]` macro exports and `pub use` macro exports. For example,
```rust
// crate A:
pub use macros::foo;
//^ This is allowed today, will be forbidden by this PR.
// crate B:
extern crate A; // This triggers a confusing error today.
use A::foo; // This could refer to refer to either macro export in crate A.
```
Josh Stone [Wed, 22 Mar 2017 17:32:38 +0000 (10:32 -0700)]
Simplify hash table drops
This replaces the `std::collections::hash::table::RevMoveBuckets`
iterator with a simpler `while` loop. This iterator was only used for
dropping the remaining elements of a `RawTable`, so instead we can just
loop through directly and drop them in place.
This should be functionally equivalent to the former code, but a little
easier to read. I was hoping it might have some performance benefit
too, but it seems the optimizer was already good enough to see through
the iterator -- the generated code is nearly the same. Maybe it will
still help if an element type has more complicated drop code.
Introduce HirId, a replacement for NodeId after lowering to HIR.
HirId has a more stable representation than NodeId, meaning that
modifications to one item don't influence (part of) the IDs within
other items. The other part is a DefIndex for which there already
is a way of stable hashing and persistence.
This commit introduces the HirId type and generates a HirId for
every NodeId during HIR lowering, but the resulting values are
not yet used anywhere, except in consistency checks.
Alex Crichton [Wed, 15 Mar 2017 14:35:35 +0000 (07:35 -0700)]
appveyor: Use Ninja to build LLVM on MinGW
I have a suspicion that MinGW's make is the cause of #40546 rather than anything
else, but that's purely a suspicion without any facts to back it up. In any case
we'll eventually be moving the MSVC build over to Ninja in order to leverage
sccache regardless, so this commit simply jumpstarts that process by downloading
Ninja for use by MinGW anyway.
I'm not sure if this closes #40546 for real, but this is my current best shot at
closing it out, so...
bors [Wed, 22 Mar 2017 02:00:16 +0000 (02:00 +0000)]
Auto merge of #40043 - petrochenkov:objpars, r=nikomatsakis
Refactor parsing of trait object types
Bugs are fixed and code is cleaned up.
User visible changes:
- `ty` matcher in macros accepts trait object types like `Write + Send` (https://github.com/rust-lang/rust/issues/39080)
- Buggy priority of `+` in trait object types starting with `for` is fixed (https://github.com/rust-lang/rust/issues/39317). `&for<'a> Trait<'a> + Send` is now parsed as `(&for<'a> Trait<'a>) + Send` and requires parens `&(for<'a> Trait<'a> + Send)`. For comparison, `&Send + for<'a> Trait<'a>` was parsed like this since [Nov 27, 2014](https://github.com/rust-lang/rust/pull/19298).
- Trailing `+`s are supported in trait objects, like in other bounds.
- Better error reporting for trait objects starting with `?Sized`.
Fixes https://github.com/rust-lang/rust/issues/39080
Fixes https://github.com/rust-lang/rust/issues/39317 [breaking-change]
Closes https://github.com/rust-lang/rust/issues/39298
cc https://github.com/rust-lang/rust/issues/39085 (fixed, then reverted https://github.com/rust-lang/rust/pull/40043#issuecomment-286570653)
cc https://github.com/rust-lang/rust/issues/39318 (fixed, then reverted https://github.com/rust-lang/rust/pull/40043#issuecomment-284493890)
Manuel [Tue, 21 Mar 2017 21:18:52 +0000 (22:18 +0100)]
Fix doc error for ExactSizeIterator
The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.
This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.
Alex Crichton [Fri, 17 Mar 2017 16:31:28 +0000 (09:31 -0700)]
travis: Add timestamps to all build messages
When debugging why builds are taking so long it's often useful to get the
timestamp of all log messages as we're not always timing every tiny step of the
build. I wrote a [utility] for prepending a relative timestamp from the start of
a process which is now downloaded to the builders and is what we wrap the entire
build invocation in.
Alex Crichton [Wed, 15 Mar 2017 15:09:59 +0000 (08:09 -0700)]
rustc: Always emit the `uwtable` attribute on Windows
This commit alters the translation layer to unconditionally emit the `uwtable`
LLVM attribute on Windows regardless of the `no_landing_pads` setting.
Previously I believe we omitted this attribute as an optimization when the
`-Cpanic=abort` flag was passed, but this unfortunately caused problems for
Gecko.
It [was discovered] that there was trouble unwinding through Rust functions due
to foreign exceptions such as illegal instructions or otherwise in-practice
methods used to abort a process. In testing it looked like the major difference
between a working binary and a non-working binary is indeed this `uwtable`
attribute, but this PR has unfortunately not been thoroughly tested in terms of
compiling Gecko with `-C panic=abort` *and* this PR to see whether it works, so
this is still somewhat working on just suspicion.
Jeffrey Seyfried [Tue, 14 Mar 2017 05:16:54 +0000 (05:16 +0000)]
Check for conflicts between macros 1.0 exports (`#[macro_export]`, `#[macro_reexport]`)
and macros 2.0 exports (`pub use` macro re-exports and `pub macro` (once implemented)
at the crate root.
bors [Tue, 21 Mar 2017 19:50:17 +0000 (19:50 +0000)]
Auto merge of #40601 - stjepang:sort-unstable, r=alexcrichton
Implement feature sort_unstable
Tracking issue for the feature: #40585
This is essentially integration of [pdqsort](https://github.com/stjepang/pdqsort) into libcore.
There's plenty of unsafe blocks to review. The heart of pdqsort is `fn partition_in_blocks` and is probably the most challenging function to understand. It requires some patience, but let me know if you find it too difficult - comments could always be improved.
#### Changes
* Added `sort_unstable` feature.
* Tweaked insertion sort constants for stable sort. Sorting integers is now up to 5% slower, but sorting big elements is much faster (in particular, `sort_large_big_random` is 35% faster). The old constants were highly optimized for sorting integers, so overall the configuration is more balanced now. A minor regression in case of integers is forgivable as we recently had performance improvements (#39538) that completely make up for it.
* Removed some uninteresting sort benchmarks.
* Added a new sort benchmark for string sorting.
Interesting cases:
* Expensive comparison function and string sorting - it's a really close race, but timsort performs a slightly smaller number of comparisons. This is a natural difference of bottom-up merging versus top-down partitioning.
* `large_descending` - unstable sort is faster, but both sorts should have equivalent performance. Both just check whether the slice is descending and if so, they reverse it. I blame LLVM for the discrepancy.