Guillaume Gomez [Thu, 2 Feb 2017 21:22:26 +0000 (22:22 +0100)]
Rollup merge of #39383 - nagisa:mir-uninhabited-destinations, r=pnkfelix
Remove the workaround for gh32959
This workaround is no longer necessary as Rust, and by extension MIR, now support uninhabited type
properly. This removes the workaround for the gh32959 that was introduced in gh33267.
Guillaume Gomez [Thu, 2 Feb 2017 21:22:23 +0000 (22:22 +0100)]
Rollup merge of #39319 - nagisa:remove-rustsetpersonalityfn, r=pnkfelix
Remove unnecessary LLVMRustPersonalityFn binding
LLVM Core C bindings provide this function for all the versions back to what we support (3.7), and
helps to avoid this unnecessary builder->function transition every time. Also a negative diff.
Fixes #38462 (although it was pretty much fixed already)
Guillaume Gomez [Thu, 2 Feb 2017 21:22:19 +0000 (22:22 +0100)]
Rollup merge of #38823 - Freyskeyd:doc-missingInformationCfgTest, r=steveklabnik
Improve doc cfg(test) and tests directory
Hi,
I was facing a problem with my code organisation. I was using a tests directory and i defined some `#[cfg(test)]` in my `src/`. But i was not able to use it in my `tests` folder.
use testt::test;
fn tesst() {
assert!(test::t());
}
```
I was unable to compile using `cargo test`:
```bash
error[E0432]: unresolved import `testt::test`
--> tests/x.rs:3:5
|
3 | use testt::test;
| ^^^^^^^^^^^ no `test` in `testt`
```
If i remove the `tests` directory everything works fine. To use an utils module in your `tests` directory, you need to create a module in the directory (like `tests/utils.rs`). My `tests/x.rs` look like this now:
bors [Thu, 2 Feb 2017 07:39:07 +0000 (07:39 +0000)]
Auto merge of #39116 - mgattozzi:better-string-message, r=nrc
Add clearer error message using `&str + &str`
This is the first part of #39018. One of the common things for new users
coming from more dynamic languages like JavaScript, Python or Ruby is to
use `+` to concatenate strings. However, this doesn't work that way in
Rust unless the first type is a `String`. This commit adds a check for
this use case and outputs a new error as well as a suggestion to guide
the user towards the desired behavior. It also adds a new test case to
test the output of the error.
bors [Thu, 2 Feb 2017 05:10:40 +0000 (05:10 +0000)]
Auto merge of #38932 - petrochenkov:privctor, r=jseyfried
Privatize constructors of tuple structs with private fields
This PR implements the strictest version of such "privatization" - it just sets visibilities for struct constructors, this affects everything including imports.
```
visibility(struct_ctor) = min(visibility(struct), visibility(field_1), ..., visibility(field_N))
```
Needs crater run before proceeding.
bors [Tue, 31 Jan 2017 11:18:22 +0000 (11:18 +0000)]
Auto merge of #39379 - segevfiner:fix-backtraces-on-i686-pc-windows-gnu, r=alexcrichton
Fix backtraces on i686-pc-windows-gnu by disabling FPO
This might have performance implications. But do note that MSVC
disables FPO by default nowadays and it's use is limited in exception
heavy languages like C++.
bors [Tue, 31 Jan 2017 08:44:07 +0000 (08:44 +0000)]
Auto merge of #39354 - alexcrichton:less-output, r=steveklabnik
rustdoc: Suppress warnings/errors with --test
Threads spawned by the test framework have their output captured by default, so
for `rustdoc --test` threads this propagates that capturing to the spawned
thread that we now have.
bors [Tue, 31 Jan 2017 06:13:05 +0000 (06:13 +0000)]
Auto merge of #38847 - michaelwoerister:gate-on-incr-comp, r=alexcrichton
travis: Gate on some minimal support for incremental compilation.
This commit adds a travis job that
1. builds a stage2 compiler in incremental mode (but with empty incremental compilation cache), and
2. builds and runs the run-pass test suite also in incremental mode.
Building incrementally with an empty cache makes sure that the compiler doesn't crash in dependency tracking during bootstrapping. Executing the incrementally built test suite gives some measure of confidence that we generate valid code.
Note, however, that the above does not give strong guarantees about the validity of incremental compilation, it just provides a basis for being able to rely on from-scratch incr. comp. builds as reference values in further tests (which then do actual incremental compilation).
bors [Sun, 29 Jan 2017 21:28:28 +0000 (21:28 +0000)]
Auto merge of #39382 - cuviper:ibm-rewind, r=alexcrichton
travis: move IBM backwards in time
Using Ubuntu's cross-toolchains for powerpc* and s390x meant they were
depending on glibc symbols from Ubuntu 16.04. And if that host is ever
updated to a new release, the toolchains would raise the bar too.
This switches powerpc, powerpc64, and s390x to use crosstool-ng
toolchains, configured approximately like RHEL6 with kernel 2.6.32 and
glibc 2.12. This ABI level should also be compatible with Debian 7
(wheezy) and Ubuntu 12.04 (precise).
For powerpc64le, the challenge was that only glibc-2.19 officially added
support, but RHEL7 backported those changes to glibc-2.17. The backport
patches are complex and numerous, so instead of trying to push those
into crosstool-ng, this just uses glibc binaries directly from CentOS 7
and builds the toolchain manually.
This workaround is no longer necessary as Rust, and by extension MIR, now support uninhabited type
properly. This removes the workaround for the gh32959 that was introduced in gh33267.
Josh Stone [Sun, 29 Jan 2017 05:25:11 +0000 (21:25 -0800)]
travis: move IBM backwards in time
Using Ubuntu's cross-toolchains for powerpc* and s390x meant they were
depending on glibc symbols from Ubuntu 16.04. And if that host is ever
updated to a new release, the toolchains would raise the bar too.
This switches powerpc, powerpc64, and s390x to use crosstool-ng
toolchains, configured approximately like RHEL6 with kernel 2.6.32 and
glibc 2.12. This ABI level should also be compatible with Debian 7
(wheezy) and Ubuntu 12.04 (precise).
For powerpc64le, the challenge was that only glibc-2.19 officially added
support, but RHEL7 backported those changes to glibc-2.17. The backport
patches are complex and numerous, so instead of trying to push those
into crosstool-ng, this just uses glibc binaries directly from CentOS 7
and builds the toolchain manually.
Segev Finer [Sat, 28 Jan 2017 19:54:59 +0000 (21:54 +0200)]
Fix backtraces on i686-pc-windows-gnu by disabling FPO
This might have performance implications. But do note that MSVC
disables FPO by default nowadays and it's use is limited in exception
heavy languages like C++.
Michael Gattozzi [Sat, 14 Jan 2017 20:25:33 +0000 (15:25 -0500)]
Add clearer error message using `&str + &str`
This is the first part of #39018. One of the common things for new users
coming from more dynamic languages like JavaScript, Python or Ruby is to
use `+` to concatenate strings. However, this doesn't work that way in
Rust unless the first type is a `String`. This commit adds a check for
this use case and outputs a new error as well as a suggestion to guide
the user towards the desired behavior. It also adds a new test case to
test the output of the error.
bors [Sat, 28 Jan 2017 20:32:56 +0000 (20:32 +0000)]
Auto merge of #39234 - segevfiner:fix-backtraces-on-windows-gnu, r=petrochenkov
Make backtraces work on Windows GNU targets again.
This is done by adding a function that can return a filename
to pass to backtrace_create_state. The filename is obtained in
a safe way by first getting the filename, locking the file so it can't
be moved, and then getting the filename again and making sure it's the same.
I had to implement a `WideCharToMultiByte` wrapper function to convert to the ANSI code page. This will work better than only allowing ASCII provided that the ANSI code page is set to the user's local language, which is often the case.
Also, please make sure that I didn't break the Unix build.
bors [Sat, 28 Jan 2017 06:21:23 +0000 (06:21 +0000)]
Auto merge of #39305 - eddyb:synelide, r=nikomatsakis
Perform lifetime elision (more) syntactically, before type-checking.
The *initial* goal of this patch was to remove the (contextual) `&RegionScope` argument passed around `rustc_typeck::astconv` and allow converting arbitrary (syntactic) `hir::Ty` to (semantic) `Ty`.
I've tried to closely match the existing behavior while moving the logic to the earlier `resolve_lifetime` pass, and [the crater report](https://gist.github.com/eddyb/4ac5b8516f87c1bfa2de528ed2b7779a) suggests none of the changes broke real code, but I will try to list everything:
There are few cases in lifetime elision that could trip users up due to "hidden knowledge":
```rust
type StaticStr = &'static str; // hides 'static
trait WithLifetime<'a> {
type Output; // can hide 'a
}
// This worked because the type of the first argument contains
// 'static, although StaticStr doesn't even have parameters.
fn foo(x: StaticStr) -> &str { x }
// This worked because the compiler resolved the argument type
// to <T as WithLifetime<'a>>::Output which has the hidden 'a.
fn bar<'a, T: WithLifetime<'a>>(_: T::Output) -> &str { "baz" }
```
In the two examples above, elision wasn't using lifetimes that were in the source, not even *needed* by paths in the source, but rather *happened* to be part of the semantic representation of the types.
To me, this suggests they should have never worked through elision (and they don't with this PR).
Next we have an actual rule with a strange result, that is, the return type here elides to `&'x str`:
```rust
impl<'a, 'b> Trait for Foo<'a, 'b> {
fn method<'x, 'y>(self: &'x Foo<'a, 'b>, _: Bar<'y>) -> &str {
&self.name
}
}
```
All 3 of `'a`, `'b` and `'y` are being ignored, because the `&self` elision rule only cares that the first argument is "`self` by reference". Due implementation considerations (elision running before typeck), I've limited it in this PR to a reference to a primitive/`struct`/`enum`/`union`, but not other types, but I am doing another crater run to assess the impact of limiting it to literally `&self` and `self: &Self` (they're identical in HIR).
It's probably ideal to keep an "implicit `Self` for `self`" type around and *only* apply the rule to `&self` itself, but that would result in more bikeshed, and #21400 suggests some people expect otherwise.
Another decent option is treating `self: X, ... -> Y` like `X -> Y` (one unique lifetime in `X` used for `Y`).
The remaining changes have to do with "object lifetime defaults" (see RFCs [599](https://github.com/rust-lang/rfcs/blob/master/text/0599-default-object-bound.md) and [1156](https://github.com/rust-lang/rfcs/blob/master/text/1156-adjust-default-object-bounds.md)):
```rust
trait Trait {}
struct Ref2<'a, 'b, T: 'a+'b>(&'a T, &'b T);
// These apply specifically within a (fn) body,
// which allows type and lifetime inference:
fn main() {
// Used to be &'a mut (Trait+'a) - where 'a is one
// inference variable - &'a mut (Trait+'b) in this PR.
let _: &mut Trait;
// Used to be an ambiguity error, but in this PR it's
// Ref2<'a, 'b, Trait+'c> (3 inference variables).
let _: Ref2<Trait>;
}
```
What's happening here is that inference variables are created on the fly by typeck whenever a lifetime has no resolution attached to it - while it would be possible to alter the implementation to reuse inference variables based on decisions made early by `resolve_lifetime`, not doing that is more flexible and works better - it can compile all testcases from #38624 by not ending up with `&'static mut (Trait+'static)`.
The ambiguity specifically cannot be an early error, because this is only the "default" (typeck can still pick something better based on the definition of `Trait` and whether it has any lifetime bounds), and having an error at all doesn't help anyone, as we can perfectly infer an appropriate lifetime inside the `fn` body.
**TODO**: write tests for the user-visible changes.
Alex Crichton [Fri, 27 Jan 2017 22:41:30 +0000 (14:41 -0800)]
Rollup merge of #39350 - nagisa:i128-test-helpers-better-def, r=alexcrichton
Use __SIZEOF_INT128__ to test __int128 presence
Previously we tested whether a handful of preprocessor variables indicating certain 64 bit
platforms, but this does not work for other 64 bit targets which have support for __int128 in C
compiler.
Use the `__SIZEOF__INT128__` preprocessor variable instead. This variable gets set to 16 by gcc and
clang for every target where __int128 is supported.
Alex Crichton [Fri, 27 Jan 2017 22:41:23 +0000 (14:41 -0800)]
Rollup merge of #39332 - nagisa:another-bigendian-128, r=eddyb
Fix another endianness issue in i128 trans
Apparently LLVMArbitraryPrecisionInteger demands integers to be in low-endian 64-bytes, rather than host-endian 64-bytes. This is weird, and obviously, not documented. And rustc now works a teeny bit more on big endians.
Alex Crichton [Fri, 27 Jan 2017 22:41:20 +0000 (14:41 -0800)]
Rollup merge of #39314 - stjepang:rewrite-sort-header, r=brson
Rewrite the first sentence in slice::sort
For every method, the first sentence should consisely explain what it does,
not how. This sentence usually starts with a verb.
It's really weird for `sort` to be explained in terms of another function,
namely `sort_by`. There's no need for that because it's obvious how `sort`
sorts elements: there is `T: Ord`.
If `sort_by_key` does not have to explicitly state how it's implemented,
then `sort` doesn't either.
Alex Crichton [Fri, 27 Jan 2017 22:41:18 +0000 (14:41 -0800)]
Rollup merge of #39311 - solson:fix-unpretty-mir-non-local, r=eddyb
Avoid ICE when pretty-printing non-local MIR item.
This comes up when using `-Zunstable-options --unpretty=mir`. Previously, rustc would ICE due to an unwrap later in this function (after `as_local_node_id`). Instead, we should just ignore items from other crates when pretty-printing MIR.
This was reported in #rust: [this playground code](https://is.gd/PSMBZS) causes an ICE if you click the MIR button. The problem is the mention of the non-local item `std::usize::MAX`, so you can reduce the test case [a lot](https://is.gd/SaLjaa).
Alex Crichton [Fri, 27 Jan 2017 22:41:17 +0000 (14:41 -0800)]
Rollup merge of #39307 - alexcrichton:stabilize-1.16, r=brson
std: Stabilize APIs for the 1.16.0 release
This commit applies the stabilization/deprecations of the 1.16.0 release, as
tracked by the rust-lang/rust issue tracker and the final-comment-period tag.
Alex Crichton [Fri, 27 Jan 2017 22:41:13 +0000 (14:41 -0800)]
Rollup merge of #39302 - alexcrichton:upload-all, r=brson
travis: Upload all artifacts in build/dist
Previously we only uploaded tarballs, but this modifies Travis/AppVeyor to
upload everything. We shouldn't have anything else in there to worry about and
otherwise we need to be sure to pick up pkg/msi/exe installers.
Alex Crichton [Fri, 27 Jan 2017 22:41:10 +0000 (14:41 -0800)]
Rollup merge of #39284 - alexcrichton:manifesting, r=brson
rustbuild: Add manifest generation in-tree
This commit adds a new tool, `build-manifest`, which is used to generate a
distribution manifest of all produced artifacts. This tool is intended to
replace the `build-rust-manifest.py` script that's currently located on the
buildmaster. The intention is that we'll have a builder which periodically:
* Downloads all artifacts for a commit
* Runs `./x.py dist hash-and-sign`. This will generate `sha256` and `asc` files
as well as TOML manifests.
* Upload all generated hashes and manifests to the directory the artifacts came
from.
* Upload *all* artifacts (tarballs and hashes and manifests) to an archived
location.
* If necessary, upload all artifacts to the main location.
This script is intended to just be the second step here where orchestrating
uploads and such will all happen externally from the build system itself.
Alex Crichton [Fri, 27 Jan 2017 22:41:09 +0000 (14:41 -0800)]
Rollup merge of #38617 - pnkfelix:double-reference, r=pnkfelix
Detect double reference when applying binary op
``` rust
let vr = v.iter().filter(|x| {
x % 2 == 0
});
```
will now yield the following compiler output:
``` bash
ERROR binary operation `%` cannot be applied to type `&&_`
NOTE this is a reference of a reference to a type that `%` can be applied to,
you need to dereference this variable once for this operation to work
NOTE an implementation of `std::ops::Rem` might be missing for `&&_`
```
The first NOTE is new.
Fix #33877
----
Thanks to @estebank for providing the original PR #34420 (of which this is a tweaked rebase).