Auto merge of #39291 - Freyskeyd:check_context_E0423, r=petrochenkov
Checker:: Execute levenshtein before other context checking
As explain [here]() i think it's better to check for a miss typing before checking context dependent help.
```rust
struct Handle {}
struct Something {
handle: Handle
}
fn main() {
let handle: Handle = Handle {};
let s: Something = Something {
// Checker detect an error and propose a solution with `Handle { /* ... */ }`
// but it's a miss typing of `handle`
handle: Handle
};
}
```
Auto merge of #41564 - gaurikholkar:master, r=nikomatsakis
Disable ref hint for pattern in let and adding ui tests #40402
A fix to #40402
The `to prevent move, use ref e or ref mut e ` has been disabled.
```
fn main() {
let v = vec![String::from("oh no")];
let e = v[0];
}
```
now gives
```
error[E0507]: cannot move out of indexed content
--> example.rs:4:13
|
4 | let e = v[0];
| ^^^^ cannot move out of indexed content
error: aborting due to previous error
```
I have added ui tests for the same and also modified a compile-fail test.
This was originally implemented in https://github.com/rust-lang/rust/pull/40043, then reverted, then there was some [agreement](https://github.com/rust-lang/rust/issues/39318#issuecomment-289108720) that it should be supported.
(This is hopefully the last PR related to bound parsing.)
Auto merge of #41368 - nikomatsakis:incr-comp-dep-tracking-map, r=eddyb
make *most* maps private
Currently we access the `DepTrackingMap` fields directly rather than using the query accessors. This seems bad. This branch removes several such uses, but not all, and extends the macro so that queries can hide their maps (so we can prevent regressions). The extension to the macro is kind of ugly :/ but couldn't find a simple way to do it otherwise (I guess I could use a nested macro...). Anyway I figure it's only temporary.
Auto merge of #41575 - alexcrichton:android-qemu-server, r=TimNN
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the toos to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full hopefully and using more cores for
the work at hand. Additionally the architecture here should be a bit speedier as
it should have less overhead than adb which is a whole new process on both the
host and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 5 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfull that test suite is much smaller than the run-pass test
suite.
Niko Matsakis [Fri, 28 Apr 2017 13:52:56 +0000 (09:52 -0400)]
introduce ability to if we have typeck-tables for a given def-id
And use this in save-analysis, which used to read the map directly.
This is an attempt to sidestep the failure occuring on homu that I
cannot reproduce.
Auto merge of #41508 - michaelwoerister:generic-path-remapping, r=alexcrichton
Implement a file-path remapping feature in support of debuginfo and reproducible builds
This PR adds the `-Zremap-path-prefix-from`/`-Zremap-path-prefix-to` commandline option pair and is a more general implementation of #41419. As opposed to the previous attempt, this implementation should enable reproducible builds regardless of the working directory of the compiler.
This implementation of the feature is more general in the sense that the re-mapping will affect *all* paths the compiler emits, including the ones in error messages.
Niko Matsakis [Tue, 18 Apr 2017 15:50:21 +0000 (11:50 -0400)]
make `ty` and `impl_trait_ref` private
This requires copying out the cycle error to avoid a cyclic borrow. Is
this a problem? Are there paths where we expect cycles to arise and not
result in errors? (In such cases, we could add a faster way to test for
cycle.)
Rollup merge of #41571 - alexcrichton:fix-windows-mingw, r=brson
windows: Copy libwinpthread-1.dll into libdir bin
Recently we switched from the win32 MinGW toolchain to the pthreads-based
toolchain. We ship `gcc.exe` from this toolchain with the `rust-mingw` package
in the standard distribution but the pthreads version of `gcc.exe` depends on
`libwinpthread-1.dll`. While we're shipping this DLL for the compiler to depend
on we're not shipping it for gcc. As a workaround just copy the dll to gcc.exe
location and don't attempt to share for now.
cc https://github.com/rust-lang/rust/issues/31840#issuecomment-297478538
Alex Crichton [Wed, 26 Apr 2017 15:52:19 +0000 (08:52 -0700)]
travis: Parallelize tests on Android
Currently our slowest test suite on android, run-pass, takes over 5 times longer
than the x86_64 component (~400 -> ~2200s). Typically QEMU emulation does indeed
add overhead, but not 5x for this kind of workload. One of the slowest parts of
the Android process is that *compilation* happens serially. Tests themselves
need to run single-threaded on the emulator (due to how the test harness works)
and this forces the compiles themselves to be single threaded.
Now Travis gives us more than one core per machine, so it'd be much better if we
could take advantage of them! The emulator itself is still fundamentally
single-threaded, but we should see a nice speedup by sending binaries for it to
run much more quickly.
It turns out that we've already got all the tools to do this in-tree. The
qemu-test-{server,client} that are in use for the ARM Linux testing are a
perfect match for the Android emulator. This commit migrates the custom adb
management code in compiletest/rustbuild to the same qemu-test-{server,client}
implementation that ARM Linux uses.
This allows us to lift the parallelism restriction on the compiletest test
suites, namely run-pass. Consequently although we'll still basically run the
tests themselves in single threaded mode we'll be able to compile all of them in
parallel, keeping the pipeline much more full and using more cores for the work
at hand. Additionally the architecture here should be a bit speedier as it
should have less overhead than adb which is a whole new process on both the host
and the emulator!
Locally on an 8 core machine I've seen the run-pass test suite speed up from
taking nearly an hour to only taking 6 minutes. I don't think we'll see quite a
drastic speedup on Travis but I'm hoping this change can place the Android tests
well below 2 hours instead of just above 2 hours.
Because the client/server here are now repurposed for more than just QEMU,
they've been renamed to `remote-test-{server,client}`.
Note that this PR does not currently modify how debuginfo tests are executed on
Android. While parallelizable it wouldn't be quite as easy, so that's left to
another day. Thankfully that test suite is much smaller than the run-pass test
suite.
As a final fix I discovered that the ARM and Android test suites were actually
running all library unit tests (e.g. stdtest, coretest, etc) twice. I've
corrected that to only run tests once which should also give a nice boost in
overall cycle time here.
Rollup merge of #41578 - arielb1:missing-adjustment, r=eddyb
typeck: resolve type vars before calling `try_index_step`
`try_index_step` does not resolve type variables by itself and would
fail otherwise. Also harden the failure path in `confirm` to cause less
confusing errors.
r? @eddyb
Fixes #41498.
beta-nominating because regression (caused by #41279).
Auto merge of #41447 - alexcrichton:sccache-everywhere, r=brson
appveyor: Use Ninja/sccache on MSVC
Now that the final bug fixes have been merged into sccache we can start
leveraging sccache on the MSVC builders on AppVeyor instead of relying on the
ad-hoc caching strategy of trigger files and whatnot.
Alex Crichton [Sat, 25 Feb 2017 17:53:46 +0000 (09:53 -0800)]
appveyor: Use Ninja/sccache on MSVC
Now that the final bug fixes have been merged into sccache we can start
leveraging sccache on the MSVC builders on AppVeyor instead of relying on the
ad-hoc caching strategy of trigger files and whatnot.
typeck: resolve type vars before calling `try_index_step`
`try_index_step` does not resolve type variables by itself and would
fail otherwise. Also harden the failure path in `confirm` to cause less
confusing errors.
Auto merge of #37860 - giannicic:defaultimpl, r=nagisa
#37653 support `default impl` for specialization
this commit implements the first step of the `default impl` feature:
> all items in a `default impl` are (implicitly) `default` and hence
> specializable.
In order to test this feature I've copied all the tests provided for the
`default` method implementation (in run-pass/specialization and
compile-fail/specialization directories) and moved the `default` keyword
from the item to the impl.
See [referenced](https://github.com/rust-lang/rust/issues/37653) issue for further info
Alex Crichton [Thu, 27 Apr 2017 01:35:01 +0000 (18:35 -0700)]
windows: Copy libwinpthread-1.dll into libdir bin
Recently we switched from the win32 MinGW toolchain to the pthreads-based
toolchain. We ship `gcc.exe` from this toolchain with the `rust-mingw` package
in the standard distribution but the pthreads version of `gcc.exe` depends on
`libwinpthread-1.dll`. While we're shipping this DLL for the compiler to depend
on we're not shipping it for gcc. As a workaround just copy the dll to gcc.exe
location and don't attempt to share for now.
cc https://github.com/rust-lang/rust/issues/31840#issuecomment-297478538
Rollup merge of #41546 - cuviper:reduced-rust-src, r=alexcrichton
Shrink the rust-src component
Before this change, the installable rust-src component had essentially the same contents as the rustc-src dist tarball, just additionally wrapped in a rust-installer. As discussed on [internals], rust-src is only meant to support uses for the standard library, so it doesn't really need the rest of the compiler sources.
Now rust-src only contains libstd and its path dependencies, which roughly matches the set of crates that have rust-analysis data. The result is **significantly** smaller, from 36MB to 1.3MB compressed, and from 247MB to 8.5MB uncompressed.
Rollup merge of #41524 - michaelwu:basic-hexagon, r=alexcrichton
Add Hexagon support
This requires an updated LLVM with https://reviews.llvm.org/D31999 and https://reviews.llvm.org/D32000 to build libcore.
A basic hello world builds and runs successfully on the hexagon simulator. libcore is fine with LLVM fixes, but libstd requires a lot more work since there's a custom rtos running on most hexagon cores. Running Linux sounds possible though, so maybe getting linux + musl going would be easier.
Here's the target file I've been using for testing
```
{
"arch": "hexagon",
"llvm-target": "hexagon-unknown-elf",
"os": "none",
"target-endian": "little",
"target-pointer-width": "32",
Auto merge of #41563 - aidanhs:aphs-fix-spurious-osx-openssl-failure, r=alexcrichton
Make sure openssl compiles with only one core
This is (hopefully) a fix for the osx openssl spurious failure - #40417.
The intermittent failures and failing in different ways made me think of a race condition. But programs are parallel make safe right? [Not openssl](https://github.com/openssl/openssl/issues/298). But we don't do a parallel make on openssl [do we](https://github.com/rust-lang/rust/blob/8c4f2c64c6759a82f143e23964a46a65c67509c9/src/bootstrap/native.rs#L309)? This confused me, except "Waiting for unfinished jobs" is present in the logs...which is evidence of a parallel make!
It turns out that when we invoke to top level target [in run.sh](https://github.com/rust-lang/rust/blob/036983201d4e9aeb5c5e56e47c305971972b2569/src/ci/run.sh#L75-L77), make will [pass the flags downwards](https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html) in order to take advantage of parallelism in sub-makes. Of course, we don't want this in openssl! Override this by explicitly disabling parallelism on the command line.
I don't know why this hasn't happened on anything except OSX. Maybe Linux binutils check if the file is in use?
Auto merge of #41420 - alexcrichton:mingw-6.3.0, r=petrochenkov
appveyor: Upgrade to gcc for mingw 6.3.0
This commit sort of brings back #40777 by upgrading back to 6.3.0. While
investigating #40546 it was discovered that 6.3.0 appears to not spurious
fail in the same way that 6.2.0 does (which we're currently using). The
workaround for #40184 contained in #40777 did not work so this commit also
contains a different workaround for the gdb issue. We will not download the
6.2.0 version of gdb and use that instead of the default version that comes with
6.3.0.
Alex Crichton [Thu, 20 Apr 2017 15:35:03 +0000 (08:35 -0700)]
appveyor: Upgrade to gcc for mingw 6.3.0
This commit sort of brings back #40777 by upgrading back to 6.3.0. While
investigating #40546 it was discovered that 6.3.0 appears to not spurious
fail in the same way that 6.2.0 does (which we're currently using). The
workaround for #40184 contained in #40777 did not work so this commit also
contains a different workaround for the gdb issue. We will not download the
6.2.0 version of gdb and use that instead of the default version that comes with
6.3.0.
Auto merge of #41352 - kennytm:macos-sanitizers, r=alexcrichton
Support AddressSanitizer and ThreadSanitizer on x86_64-apple-darwin
[ASan](https://clang.llvm.org/docs/AddressSanitizer.html#supported-platforms) and [TSan](https://clang.llvm.org/docs/ThreadSanitizer.html#supported-platforms) are supported on macOS, and this commit enables their support.
The sanitizers are always built as `*.dylib` on Apple platforms, so they cannot be statically linked into the corresponding `rustc_?san.rlib`. The dylibs are directly copied to `lib/rustlib/x86_64-apple-darwin/lib/` instead.
Note, although Xcode also ships with their own copies of ASan/TSan dylibs, we cannot use them due to version mismatch.
----
~~There is a caveat: the sanitizer libraries are linked as `@rpath/` (due to https://reviews.llvm.org/D6018), so the user needs to additionally pass `-C rpath`:~~
Auto merge of #41504 - eddyb:query-api, r=nikomatsakis
Improve the librustc on-demand/query API ergonomics.
Queries are now performed through these two forms:
* `tcx.type_of(def_id)` (the most common usage)
* `tcx.at(span).type_of(def_id)` (to provide a more specific location in the cycle stack)
Several queries were renamed to work better as method names, i.e. by suffixing with `_of`.
Auto merge of #41258 - clarcharr:str_box_extras, r=Kimundi
More methods for str boxes. (reduce Box<[u8]> ↔ Box<str> transmutes)
This is a follow-up to #41096 that adds safer methods for converting between `Box<str>` and `Box<[u8]>`. They're gated under a different feature from the `&mut str` methods because they may be too niche to include in public APIs, although having them internally helps reduce the number of transmutes the standard library uses.
What's added:
* `From<Box<str>> for Box<[u8]>`
* `<Box<str>>::into_boxed_bytes` (just calls `Into::into`)
* `alloc::str` (new module)
* `from_boxed_utf8` and `from_boxed_utf8_unchecked`, defined in `alloc:str`, exported in `collections::str`
* exports `from_utf8_mut` in `collections::str` (missed from previous PR)
projects / rust.git / log