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.