Rollup merge of #53973 - tromey:prefer-rust-enabled-lldb, r=alexcrichton
Have rust-lldb look for the rust-enabled lldb
We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup. See the discussion in
https://github.com/rust-lang-nursery/rustup.rs/pull/1492 for
background on this decision. There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed. This patch changes
rust-lldb to look in the sysroot and use the lldb found there, if any.
Rollup merge of #53942 - nnethercote:faster-precompute, r=nikomatsakis
Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.
It now does one hash table lookup per basic block, instead of one per
statement. This is worthwhile because this function is hot for NLL
builds of `ucd`.
I haven't measured the effect of this yet because I'm having trouble doing optimized builds of rustc that are suitable for profiling (#53916). I will do an online perf run instead.
Rollup merge of #53932 - matthewjasper:remove-base-path, r=nikomatsakis
[NLL] Remove base_place
This function was supposed to make `Box` less special. But
* I think that the consensus is that MIR borrowck is going to fully special case `Box`
* It wasn't implemented correctly, it's looking at the type of the wrong `Place`, resulting in weird behaviour:
```rust
#![feature(nll)]
type A = Box<i32>; // If this is changed to another type then this will compile.
pub fn foo(x: Box<(String, A)>) {
let a = x.0; // This will compile if these lines are swapped
let b = x.1;
}
```
Niko Matsakis [Mon, 27 Aug 2018 19:10:05 +0000 (15:10 -0400)]
move `annotate` onto a method of `UniversalRegions`
This allows it to print out the "late-bound regions" from the closure
context more easily. Besides, all the state that is being printed it
is private to the `UniversalRegions`.
Auto merge of #53327 - wesleywiser:wip_optimize_nll, r=nikomatsakis
[nll] teach SCC about `'static`
r? @nikomatsakis
I think this is right? I am seeing better performance on the `html5ever` benchmark but I'd like a perf run to quantify the exact speedup. There's a few ui tests failing due to changes in the error messages. The main issue seems to be that returns aren't being detected correctly?
`mir_check_cast_unsize.rs` before:
```
error: unsatisfied lifetime constraints
--> mir_check_cast_unsize.rs:17:46
|
17 | fn bar<'a>(x: &'a u32) -> &'static dyn Debug {
| ________--____________________________________^
| | |
| | lifetime `'a` defined here
18 | | //~^ ERROR unsatisfied lifetime constraints
19 | | x
20 | | //~^ WARNING not reporting region error due to nll
21 | | }
| |_^ return requires that `'a` must outlive `'static`
```
`mir_check_cast_unsize.rs` after:
```
error: unsatisfied lifetime constraints
--> mir_check_cast_unsize.rs:19:5
|
17 | fn bar<'a>(x: &'a u32) -> &'static dyn Debug {
| -- lifetime `'a` defined here
18 | //~^ ERROR unsatisfied lifetime constraints
19 | x
| ^ cast requires that `'a` must outlive `'static`
```
Tom Tromey [Wed, 5 Sep 2018 19:05:46 +0000 (13:05 -0600)]
Have rust-lldb look for the rust-enabled lldb
We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup. See the discussion in
https://github.com/rust-lang-nursery/rustup.rs/pull/1492 for
background on this decision. There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed.
This patch changes dist.rs to put lldb into rustlib, following what
was done for the other LLVM tools in #53955, and then fixes rust-lldb
to prefer that lldb, if it exists.
- #53299 (Updated core/macros.rs to note it works in a no_std environment.)
- #53376 (Cross reference io::copy and fs::copy in docs.)
- #53455 (Individual docs for {from,to}_*_bytes)
- #53550 (librustc_lint: In recursion warning, change 'recurring' to 'recursing')
- #53860 (Migrate (some) of run-pass/ to ui)
- #53874 (Implement Unpin for Box, Rc, and Arc)
- #53895 (tidy: Cleanups and clippy warning fixes)
- #53946 (Clarify `ManuallyDrop` docs)
- #53948 (Minimized clippy test from when NLL disabled two-phase borrows)
- #53959 (Add .git extension to submodule paths missing it)
- #53966 (A few cleanups and minor improvements to mir/dataflow)
- #53967 (propagate build.python into cmake)
- #53979 (Remove `#[repr(transparent)]` from atomics)
- #53991 (Add unchecked_shl/shr check for intrinsics to fix miri's test suit)
- #53992 (migrate run-pass/borrowck to ui/run-pass)
- #53994 (migrate run-pass/*/ to ui/run-pass)
- #54023 (update clippy submodule)
Rollup merge of #53991 - TimDiekmann:fix-unchecked-intrinsics, r=oli-obk
Add unchecked_shl/shr check for intrinsics to fix miri's test suit
r? @RalfJung
cc @oli-obk
#53697 broke miri's test suite as described in [this comment](https://github.com/rust-lang/rust/pull/53697#issuecomment-419034668). This PR adds test for the `unchecked_shr/shl` for the intrinsics.
Rollup merge of #53979 - alexcrichton:remove-repr-transparent-atomics-master, r=sfackler
Remove `#[repr(transparent)]` from atomics
Added in #52149 the discussion in #53514 is showing how we may not want to
actually add this attribute to the atomic types. While we continue to
debate #53514 this commit reverts the addition of the `transparent` attribute.
This should be a more conservative route which leaves us the ability to tweak
this in the future but in the meantime allows us to continue discussion as well.
Rollup merge of #53967 - froydnj:cmake-python-executable, r=alexcrichton
propagate build.python into cmake
If a suitable value of Python is not on `PATH`, one can still invoke x.py
manually, which propagates `BOOTSTRAP_PYTHON` into the bootstrap
environment. But building LLVM will abort with error messages about not
being able to find Python, and instructions to set `PYTHON_EXECUTABLE`,
because nothing is done with `BOOTSTRAP_PYTHON` when invoking cmake.
Setting `build.python` in config.toml had no effect in this scenario,
either
To fix this, let's provide `PYTHON_EXECUTABLE` when invoking cmake; for
the "normal" case of Python in `PATH`, this doesn't alter any behavior.
For more unusual cases, however, this ensures cmake finds Python
properly. (This change also ensures there are no differences between
what bootstrap is using, and what cmake uses, which may be useful for
consistency's sake.)
Rollup merge of #53966 - ljedrz:mir_dataflow_cleanups, r=estebank
A few cleanups and minor improvements to mir/dataflow
- simplify `dot::GraphWalk::edges` and optimize its vector's allocation
- turn a `kill` loop into `kill_all`
- remove the `prepost` parameter from `dataflow_path` (it doesn't seem to do anything)
- a couple of other minor improvements
Rollup merge of #53959 - tlively:fix-submodules, r=alexcrichton
Add .git extension to submodule paths missing it
Fixes a problem where submodules could not be cloned under some git
configurations. Specifically, when url.git@github.com:.insteadOf =
https://github.com/ is set.
Rollup merge of #53948 - pnkfelix:issue-52934-minimize-clippy-test, r=wesleywiser
Minimized clippy test from when NLL disabled two-phase borrows
(Of course anyone even skimming the test will realize that this is an *expansion* of a previously posted [minimization](https://github.com/rust-lang/rust/issues/52934#issuecomment-418144787).)
Rollup merge of #53895 - joshtriplett:tidy-tidy, r=nikomatsakis
tidy: Cleanups and clippy warning fixes
This eliminates various clippy warnings in the tidy tool, as well as
making some related cleanups. These changes should not introduce any
functional differences.
Rollup merge of #53860 - pnkfelix:issue-53764-migrate-run-pass-to-ui, r=nikomatsakis
Migrate (some) of run-pass/ to ui
This is a step towards addressing #53764. Much still remains.
I went through a large portion of the `*.rs` files that were directly stored into `src/test/run-pass/` and moved them into various subdirectories of a newly created `src/test/ui/run-pass/`.
(yes, it would have perhaps been nice to meld it more directly with directories already in `src/test/ui/`; but the sad truth is that opens up the reality of filename collisions, and one of my short term goals for resolving #53764 is to keep the *filenames* invariant, even as their parents directories and contents are mildly revised...)
Rollup merge of #53550 - brson:recurring, r=estebank
librustc_lint: In recursion warning, change 'recurring' to 'recursing'
The existing wording seems incorrect.
Aside: This warning, 'function cannot return without recursing' is not perfectly clear - it implies that the function _can_ return, it's just got to recurse. But really the fn cannot return period. Clearer wording: 'function recurses infinitely; it cannot return'; or 'function is infinitely self-recursive; it cannot return, and this is probably an error'. I like that.
Rollup merge of #53299 - MagnumOpus21:fix-macro-write, r=steveklabnik
Updated core/macros.rs to note it works in a no_std environment.
Fixes #45797
This PR updates the documentation of `write!` to note it works in a `no_std` environment, and adds an
example to showcase this. In a `no_std` environment, the author of the code is responsible for the
implementation of the `Write` trait. This example will work out of the box with `no_std`, but the
implementation of `Write` is expected to be provided by the user.
Auto merge of #54005 - eddyb:uniform-paths-self-resolve, r=petrochenkov
rustc_resolve: allow `use crate_name;` under `uniform_paths`.
Specifically, `use crate_name;` and `use crate_name::{self, ...};` are now allowed, whereas previously there would produce a (false positive) ambiguity error, as the ambiguity detection code was seeing the `crate_name` import as a locally-available definition to conflict with the crate.
r? @petrochenkov cc @aturon @joshtriplett @Centril
Auto merge of #53575 - matthewjasper:unsized-is-an-error, r=estebank
Don't reduce E0161 to a warning in NLL migrate mode
This error has been on stable for a while, and allowing such code cause the compile to later ICE (since we can't codegen it). Errors `box UNSIZED EXPR` with unsized locals because it's not compatible with the current evaluation order (create the box before evaluating the expressions).
Auto merge of #52626 - brunocodutra:issue-52475, r=oli-obk
Fix issue #52475: Make loop detector only consider reachable memory
As [suggested](https://github.com/rust-lang/rust/pull/51702#discussion_r197585664) by @oli-obk `alloc_id`s should be ignored by traversing all `Allocation`s in interpreter memory at a given moment in time, beginning by `ByRef` locals in the stack.
- [x] Generalize the implementation of `Hash` for `EvalSnapshot` to traverse `Allocation`s
- [x] Generalize the implementation of `PartialEq` for `EvalSnapshot` to traverse `Allocation`s
- [x] Commit regression tests
That is, opting to ignore stable `#![feature(..)]`, under my theory
that a reviewer would prefer as much stuff to be bucketed under "ah
another `#![allow(..)]` here." as possible.
Add `#![allow(improper_ctypes)]` to extern-pass-empty.rs; note this test seems bogus.
that is, I suspect it should be retired because it is testing behavior
(namely a `#[repr(C)] struct Empty;`) that, if I understand correctly,
is undefined.
Auto merge of #53707 - eddyb:phantom-waffles, r=oli-obk
rustc_typeck: turn `where Type:,` into a WF(Type) predicate, instead of ignoring it.
Fixes #53696, assuming crater doesn't catch anyone using this syntax already.
Allowing an empty list of bounds in the grammar was done for the benefit of macro authors, most of which would *probably* be using it for bounds on type parameters, which are always WF.
Auto merge of #53721 - arielb1:exhaustively-unpun, r=nikomatsakis
fix `is_non_exhaustive` confusion between structs and enums
Structs and enums can both be non-exhaustive, with a very different
meaning. This PR splits `is_non_exhaustive` to 2 separate functions - 1
for structs, and another for enums, and fixes the places that got the
usage confused.
Auto merge of #53955 - alexcrichton:fix-dist-again, r=japaric
rustbuild: Tweak LLVM distribution layout
This commit tweaks the layout of a few components that we distribute to
hopefully fix across all platforms the recent issues with LLD being unable to
find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic
library, which means that LLVM tools by default link to LLVM dynamically rather
than statically. This in turn means that the tools, at runtime, need to find the
LLVM shared library.
LLVM's shared library is currently distributed as part of the rustc component.
This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are
in two locations:
* LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld`
* Other LLVM tools are shipped at `$sysroot/bin`
Each LLVM tool has an embedded rpath directive indicating where it will search
for dynamic libraries. This currently points to `../lib` and is presumably
inserted by LLVM's build system. Unfortunately, though, this directive is only
correct for the LLVM tools at `$sysroot/bin`, not LLD!
This commit is targeted at fixing this situation by making two changes:
* LLVM tools other than LLD are moved in the distribution to
`$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should
position them for...
* The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib`
Together this means that all tools should natively be able to find the shared
object and the shared object should be installed all the time for the various
tools. Overall this should...
Auto merge of #52994 - varkor:trim_direction, r=alexcrichton
Add trim_start, trim_end etc.; deprecate trim_left, trim_right, etc. in future
Adds the methods: `trim_start`, `trim_end`, `trim_start_matches` and `trim_end_matches`.
Deprecates `trim_left`, `trim_right`, `trim_left_matches` and `trim_right_matches` starting from Rust 1.33.0, three versions from when they'll initially be marked as being deprecated, using the future deprecation from https://github.com/rust-lang/rust/issues/30785 and https://github.com/rust-lang/rust/pull/51681.
Alex Crichton [Wed, 5 Sep 2018 22:37:39 +0000 (15:37 -0700)]
Remove `#[repr(transparent)]` from atomics
Added in #52149 the discussion in #53514 is showing how we may not want to
actually add this attribute to the atomic types. While we continue to
debate #53514 this commit reverts the addition of the `transparent` attribute.
This should be a more conservative route which leaves us the ability to tweak
this in the future but in the meantime allows us to continue discussion as well.
Auto merge of #53951 - tromey:restore-lldb-build, r=alexcrichton
Restore lldb build
commit 6c10142251 ("Update LLVM submodule") disabled the lldb build.
This patch updates the lldb and clang submodules to once again build
against the LLVM that is included in the Rust tree, and reverts the
.travis.yml changes from that patch.
Alex Crichton [Tue, 4 Sep 2018 19:57:27 +0000 (12:57 -0700)]
rustbuild: Tweak LLVM distribution layout
This commit tweaks the layout of a few components that we distribute to
hopefully fix across all platforms the recent issues with LLD being unable to
find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic
library, which means that LLVM tools by default link to LLVM dynamically rather
than statically. This in turn means that the tools, at runtime, need to find the
LLVM shared library.
LLVM's shared library is currently distributed as part of the rustc component.
This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are
in two locations:
* LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld`
* Other LLVM tools are shipped at `$sysroot/bin`
Each LLVM tool has an embedded rpath directive indicating where it will search
for dynamic libraries. This currently points to `../lib` and is presumably
inserted by LLVM's build system. Unfortunately, though, this directive is only
correct for the LLVM tools at `$sysroot/bin`, not LLD!
This commit is targeted at fixing this situation by making two changes:
* LLVM tools other than LLD are moved in the distribution to
`$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should
position them for...
* The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib`
Together this means that all tools should natively be able to find the shared
object and the shared object should be installed all the time for the various
tools. Overall this should...
If a suitable value of Python is not on PATH, one can still invoke x.py
manually, which propagates BOOTSTRAP_PYTHON into the bootstrap
environment. But building LLVM will abort with error messages about not
being able to find Python, and instructions to set PYTHON_EXECUTABLE,
because nothing is done with BOOTSTRAP_PYTHON when invoking cmake.
Setting build.python in config.toml had no effect in this scenario,
either
To fix this, let's provide PYTHON_EXECUTABLE when invoking cmake; for
the "normal" case of Python in PATH, this doesn't alter any behavior.
For more unusual cases, however, this ensures cmake finds Python
properly. (This change also ensures there are no differences between
what bootstrap is using, and what cmake uses, which may be useful for
consistency's sake.)
Auto merge of #53878 - alexcrichton:wasm-atomics-feature, r=eddyb
rustc: Prepare the `atomics` feature for wasm
This commit adds a few changes for atomic instructions on the
`wasm32-unknown-unknown` target. Atomic instructions are not yet stable in
WebAssembly itself but there are multiple implementations and LLVM has support
for the proposed instruction set, so let's work on exposing it!
Here there are a few inclusions:
* The `atomics` feature was whitelisted for LLVM, allowing code in Rust to
enable/disable/gate on this.
* The `singlethread` option is turned off for wasm when the `atomics` feature is
enabled. This means that by default wasm won't be lowering with atomics, but
when atomics are enabled globally we'll turn off single-threaded mode to
actually codegen atomics. This probably isn't what we'll want in the long term
but for now it should work.
* Finally the maximum atomic width is increased to 64 to reflect the current
wasm spec.
projects / rust.git / log