Niko Matsakis [Fri, 28 Apr 2017 10:00:48 +0000 (06:00 -0400)]
introduce idea of "stealable" MIR
This is a more principled version of the `RefCell` we were using
before. We now allocate a `Steal<Mir<'tcx>>` for each intermediate MIR
pass; when the next pass steals the entry, any later attempts to use it
will panic (there is no way to *test* if MIR is stolen, you're just
supposed to *know*).
Niko Matsakis [Thu, 27 Apr 2017 20:48:48 +0000 (16:48 -0400)]
retool MIR passes completely
The new setup is as follows. There is a pipeline of MIR passes that each
run **per def-id** to optimize a particular function. You are intended
to request MIR at whatever stage you need it. At the moment, there is
only one stage you can request:
- `optimized_mir(def_id)`
This yields the final product. Internally, it pulls the MIR for the
given def-id through a series of steps. Right now, these are still using
an "interned ref-cell" but they are intended to "steal" from one
another:
- `mir_build` -- performs the initial construction for local MIR
- `mir_pass_set` -- performs a suite of optimizations and transformations
- `mir_pass` -- an individual optimization within a suite
Niko Matsakis [Tue, 25 Apr 2017 22:23:33 +0000 (18:23 -0400)]
simplify the MirPass traits and passes dramatically
Overall goal: reduce the amount of context a mir pass needs so that it
resembles a query.
- The hooks are no longer "threaded down" to the pass, but rather run
automatically from the top-level (we also thread down the current pass
number, so that the files are sorted better).
- The hook now receives a *single* callback, rather than a callback per-MIR.
- The traits are no longer lifetime parameters, which moved to the
methods -- given that we required
`for<'tcx>` objecs, there wasn't much point to that.
- Several passes now store a `String` instead of a `&'l str` (again, no
point).
Corey Farwell [Tue, 2 May 2017 13:09:55 +0000 (09:09 -0400)]
Rollup merge of #41662 - nikomatsakis:on-demandify-region-mapping, r=eddyb
On demandify region mapping
This is an adaptation of @cramertj's PR. I am sort of tempted to keep simplifying it, but also tempted to land it so and we can refactor more in follow-up PRs. As is, it does the following things:
- makes the region-maps an on-demand query, per function `tcx.region_maps(def_id)`
- interns code extents instead of of having them be integers
- remove the "root region extent" and (to some extent) item extents; instead we use `Option<CodeExtent<'tcx>>` in a few places (no space inefficiency since `CodeExtent<'tcx>` is now a pointer).
I'm not entirely happy with the way I have it setup though. Here are some of the changes I was considering (I'm not sure if they would work out well):
1. Removing `item_extents` entirely -- they are rarely used now, because most of the relevant places now accept an `Option<Region<'tcx>>` or an `Option<CodeExtent<'tcx>>`, but I think still used in a few places.
2. Merging `RegionMaps` into the typeck tables, instead of having it be its own query.
3. Change `CodeExtent<'tcx>` to store the parent pointer. This would mean that fewer places in the code actually *need* a `RegionMaps` anyhow, since most of them just want to be able to walk "up the tree". On the other hand, you wouldn't be able to intern a `CodeExtent<'tcx>` for some random node-id, you'd need to look it up in the table (since there'd be more information).
Most of this code is semi-temporary -- I expect it to largely go away as we move to NLL -- so I'm also not *that* concerned with making it perfect.
Corey Farwell [Tue, 2 May 2017 13:09:54 +0000 (09:09 -0400)]
Rollup merge of #41661 - barik:master, r=alexcrichton
Under MinGW, x.py fails to run with UnboundLocalError.
Under MinGW, `x.py` will fail with the following errors:
```bash
$ ./x.py
Traceback (most recent call last):
File "./x.py", line 20, in <module>
bootstrap.main()
File "C:/src/rust/src/bootstrap/bootstrap.py", line 620, in main
bootstrap()
File "C:/src/rust/src/bootstrap/bootstrap.py", line 601, in bootstrap
rb.build = rb.build_triple()
File "C:/src/rust/src/bootstrap/bootstrap.py", line 459, in build_triple
if os.environ.get('MSYSTEM') == 'MINGW64':
UnboundLocalError: local variable 'os' referenced before assignment
```
The reason is due to the `build_triple` function in `src/bootstrap/bootstrap.py` (Line 416):
```python
if ostype == 'Linux':
os = subprocess.check_output(['uname', '-o']).strip().decode(default_encoding)
```
Here, the assignment to `os` is causing the `os` module to be shadowed.
Then, in (Line 459):
```python
if os.environ.get('MSYSTEM') == 'MINGW64':
cputype = 'x86_64'
```
`os` now refers to the uninitialized local variable, not the `os` module.
Easiest fix is to simply rename the `os` variable to something like `os_from_sp`.
Also, there is a small typo fix in `x.py` referencing the wrong file name.
bors [Tue, 2 May 2017 12:11:54 +0000 (12:11 +0000)]
Auto merge of #41547 - alexeyzab:41425-fix-mismatched-types-error-message, r=arielb1
Fix error message for mismatched types
This addresses #41425 by implementing the changes mentioned in the
following comment:
https://github.com/rust-lang/rust/issues/41425#issuecomment-296754508
bors [Tue, 2 May 2017 09:41:39 +0000 (09:41 +0000)]
Auto merge of #41488 - estebank:closure-args, r=arielb1
Clean up callable type mismatch errors
```rust
error[E0593]: closure takes 1 argument but 2 arguments are required here
--> ../../src/test/ui/mismatched_types/closure-arg-count.rs:13:15
|
13 | [1, 2, 3].sort_by(|(tuple, tuple2)| panic!());
| ^^^^^^^ -------------------------- takes 1 argument
| |
| expected closure that takes 2 arguments
```
instead of
```rust
error[E0281]: type mismatch: the type `[closure@../../src/test/ui/mismatched_types/closure-arg-count.rs:13:23: 13:49]` implements the trait `for<'r> std::ops::FnMut<(&'r {integer},)>`, but the trait `for<'r, 'r> std::ops::FnMut<(&'r {integer}, &'r {integer})>` is required (expected a tuple with 2 elements, found one with 1 elements)
--> ../../src/test/ui/mismatched_types/closure-arg-count.rs:13:15
|
13 | [1, 2, 3].sort_by(|(tuple, tuple2)| panic!());
| ^^^^^^^
```
bors [Tue, 2 May 2017 01:04:27 +0000 (01:04 +0000)]
Auto merge of #40851 - oli-obk:multisugg, r=jonathandturner
Minimize single span suggestions into a label
changes
```
14 | println!("☃{}", tup[0]);
| ^^^^^^
|
help: to access tuple elements, use tuple indexing syntax as shown
| println!("☃{}", tup.0);
```
into
```
14 | println!("☃{}", tup[0]);
| ^^^^^^ to access tuple elements, use `tup.0`
```
Also makes suggestions explicit in the backend in preparation of adding multiple suggestions to a single diagnostic. Currently that's already possible, but results in a full help message + modified code snippet per suggestion, and has no rate limit (might show 100+ suggestions).
bors [Mon, 1 May 2017 17:23:09 +0000 (17:23 +0000)]
Auto merge of #41560 - alevy:rwpi-ropi, r=eddyb
Add RWPI/ROPI relocation model support
This PR adds support for using LLVM 4's ROPI and RWPI relocation models for ARM.
ROPI (Read-Only Position Independence) and RWPI (Read-Write Position Independence) are two new relocation models in LLVM for the ARM backend ([LLVM changset](https://reviews.llvm.org/rL278015)). The motivation is that these are the specific strategies we use in userspace [Tock](https://www.tockos.org) apps, so supporting this is an important step (perhaps the final step, but can't confirm yet) in enabling userspace Rust processes.
## Explanation
ROPI makes all code and immutable accesses PC relative, but not assumed to be overriden at runtime (so for example, jumps are always relative).
RWPI uses a base register (`r9`) that stores the addresses of the GOT in memory so the runtime (e.g. a kernel) only adjusts r9 tell running code where the GOT is.
## Complications adding support in Rust
While this landed in LLVM master back in August, the header files in `llvm-c` have not been updated yet to reflect it. Rust replicates that header file's version of the `LLVMRelocMode` enum as the Rust enum `llvm::RelocMode` and uses an implicit cast in the ffi to translate from Rust's notion of the relocation model to the LLVM library's notion.
My workaround for this currently is to replace the `LLVMRelocMode` argument to `LLVMTargetMachineRef` with an int and using the hardcoded int representation of the `RelocMode` enum. This is A Bad Idea(tm), but I think very nearly the right thing.
Would a better alternative be to patch rust-llvm to support these enum variants (also a fairly trivial change)?
bors [Mon, 1 May 2017 09:48:09 +0000 (09:48 +0000)]
Auto merge of #41666 - nagisa:try-poking-bigendian-again, r=arielb1
Try fixing bigendian metadata serialisation
I compiled this on PPC to check and it seems to work, but not sure whether I didn't mess up
anything in a major way.
Maybe a good shot at #41443
The easiest way to *really* test this is to land the patch (a high priority would be good, since I quite literally am just twiddling my thumbs on this now), wait for nightly, and, if the nightly works, backport this to beta.
Taylor Cramer [Mon, 10 Apr 2017 07:00:08 +0000 (00:00 -0700)]
introduce per-fn RegionMaps
Instead of requesting the region maps for the entire crate, request for
a given item etc. Several bits of code were modified to take
`&RegionMaps` as input (e.g., the `resolve_regions_and_report_errors()`
function). I am not totally happy with this setup -- I *think* I'd
rather have the region maps be part of typeck tables -- but at least the
`RegionMaps` works in a "parallel" way to `FreeRegionMap`, so it's not
too bad. Given that I expect a lot of this code to go away with NLL, I
didn't want to invest *too* much energy tweaking it.
Auto merge of #41602 - hsivonen:explainnonnull, r=steveklabnik
Explain why zero-length slices require a non-null pointer
In reference to [a thread on Discourse](https://users.rust-lang.org/t/why-does-std-slice-from-raw-parts-require-a-non-null-pointer-for-zero-length-slices/10534), explain why `from_raw_parts` requires a non-null pointer for zero-length slices.
Rollup merge of #41613 - cuviper:fix-release-links, r=aturon
Fix links in RELEASES.md for 1.10.0 through 1.12.0
Many links in this series have the `[link text]` and `(url)` on separate
lines, which doesn't get correctly interpreted in markdown. Or maybe it
once did, but it doesn't now. This patch joins the lines together.
Rollup merge of #41608 - cuviper:distcheck-rust-src, r=alexcrichton
Add a distcheck for rust-src completeness
This is for the last commit of #41546. For some reason, @bors only saw the first two commits, and wouldn't approve the last even when explicitly directed so.
Rollup merge of #41509 - froydnj:float-stack-reduction, r=nagisa
reduce stack requirements for floating-point formatting
Doing this speeds up float formatting by ~10% or so, and also makes the formatting code more suitable for embedded environments where stack space is at a premium.
This is a quick draft to start working on [#41351](https://github.com/rust-lang/rust/issues/41351).
I don't think I got the stable attributes correct, but it is good enuf to start a conversation.
Auto merge of #41544 - alexcrichton:bump-bootstrap, r=brson
Update stage0 bootstrap compiler
We've got a freshly minted beta compiler, let's update to use that on nightly!
This has a few other changes associated with it as well
* A bump to the rustc version number (to 1.19.0)
* Movement of the `cargo` and `rls` submodules to their "proper" location in
`src/tools/{cargo,rls}`. Now that Cargo workspaces support the `exclude`
option this can work.
* Updates of the `cargo` and `rls` submodules to their master branches.
* Tweak to the `src/stage0.txt` format to be more amenable for Cargo version
numbers. On the beta channel Cargo will bootstrap from a different version
than rustc (e.g. the version numbers are different), so we need different
configuration for this.
* Addition of `dev` as a readable key in the `src/stage0.txt` format. If present
then stage0 compilers are downloaded from `dev-static.rust-lang.org` instead
of `static.rust-lang.org`. This is added to accomodate our updated release
process with Travis and AppVeyor.
Alex Crichton [Thu, 20 Apr 2017 21:32:54 +0000 (14:32 -0700)]
Update stage0 bootstrap compiler
We've got a freshly minted beta compiler, let's update to use that on nightly!
This has a few other changes associated with it as well
* A bump to the rustc version number (to 1.19.0)
* Movement of the `cargo` and `rls` submodules to their "proper" location in
`src/tools/{cargo,rls}`. Now that Cargo workspaces support the `exclude`
option this can work.
* Updates of the `cargo` and `rls` submodules to their master branches.
* Tweak to the `src/stage0.txt` format to be more amenable for Cargo version
numbers. On the beta channel Cargo will bootstrap from a different version
than rustc (e.g. the version numbers are different), so we need different
configuration for this.
* Addition of `dev` as a readable key in the `src/stage0.txt` format. If present
then stage0 compilers are downloaded from `dev-static.rust-lang.org` instead
of `static.rust-lang.org`. This is added to accomodate our updated release
process with Travis and AppVeyor.
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.
Amit Aryeh Levy [Fri, 28 Apr 2017 22:21:59 +0000 (17:21 -0500)]
Added LLVMRustRelocMode
Replaces the llvm-c exposed LLVMRelocMode, which does not include all
relocation model variants, with a LLVMRustRelocMode modeled after
LLVMRustCodeMode.
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.)
The comments for flt2dec::to_shortest_str says that we only need a slice
of length 5 for the parts array. Initializing a 16-part array is just
wasted effort and wasted stack space. Other functions in the flt2dec
module have similar comments, so we adjust the parts arrays passed to
those functions accordingly.
fmt: reduce the stack space required by float formatting
For the two major entry points for float formatting, we split the exact
case and the shortest cases into separate functions. We mark the
separate functions as #[inline(never) so the exact cases won't bloat
stack space in their callers unnecessarily. The shortest cases are
marked so for similar reasons.
num: add minimal benchmarks for full floating-point formatting
We have benchmarks for the floating-point formatting algorithms
themselves, but not for the surrounding machinery like Formatter and
translating to the flt2dec::Part slices.
Josh Stone [Fri, 28 Apr 2017 19:11:33 +0000 (12:11 -0700)]
Fix links in RELEASES.md for 1.10.0 through 1.12.0
Many links in this series have the `[link text]` and `(url)` on separate
lines, which doesn't get correctly interpreted in markdown. Or maybe it
once did, but it doesn't now. This patch joins the lines together.
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.)
projects / rust.git / log