bors [Tue, 29 Jan 2019 05:22:51 +0000 (05:22 +0000)]
Auto merge of #57957 - Centril:rollup, r=Centril
Rollup of 7 pull requests
Successful merges:
- #57045 (Kill remaining uses of mem::uninitialized in libcore, liballoc)
- #57674 (Avoid erase_regions_ty queries if there are no regions to erase)
- #57833 (Print a slightly clearer message when failing to launch a thread)
- #57859 (Fix invalid background color)
- #57904 (add typo suggestion to unknown attribute error)
- #57915 (Pretty print `$crate` as `crate` or `crate_name` in more cases)
- #57950 (Extend E0106, E0261)
Rollup merge of #57950 - QuietMisdreavus:lifetime-err-desc, r=estebank
Extend E0106, E0261
This is a reopening of https://github.com/rust-lang/rust/pull/57310 with review comments addressed because the original author has since deleted their fork.
From the author (@purple-ice):
> Added an example that points out hardly obvious mistake one could make when writing impl for a new type.
Rollup merge of #57915 - petrochenkov:notto-disu, r=zackmdavis
Pretty print `$crate` as `crate` or `crate_name` in more cases
So, people do parse output of `--pretty=expanded` (sigh), so covering only the legacy proc-macro case (like it was done in https://github.com/rust-lang/rust/pull/57155) is not enough.
This PRs resolves all `$crate`s produced by macros, so they are all printed in the parseable form `$crate::foo` -> `crate::foo` or `crate_name::foo`.
Rollup merge of #57833 - jethrogb:jb/thread-spawn-unwrap, r=alexcrichton
Print a slightly clearer message when failing to launch a thread
As discussed in #46345, the `io::Error` you get when a thread fails to launch is of type `io::ErrorKind::WouldBlock`. This is super uninformative when an arbitrary `thread::spawn` fails somewhere in your code:
```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11,
kind: WouldBlock, message: "operation would block" }', src/libcore/result.rs:997:5
```
This PR improves the situation a little bit by using `expect` instead of `unwrap`. I don't consider this a complete fix for #46345 though.
Rollup merge of #57045 - RalfJung:kill-more-uninit, r=SimonSapin
Kill remaining uses of mem::uninitialized in libcore, liballoc
Kill remaining uses of mem::uninitialized in libcore and liballoc, and enable a lint that will warn when uses are added again in the future.
To avoid casting raw pointers around (which is always very dangerous because it is not typechecked at all -- it doesn't even get the "same size" sanity check that `transmute` gets), I also added two new functions to `MaybeUninit`:
```rust
/// Get a pointer to the first contained values.
pub fn first_ptr(this: &[MaybeUninit<T>]) -> *const T {
this as *const [MaybeUninit<T>] as *const T
}
/// Get a mutable pointer to the first contained values.
pub fn first_mut_ptr(this: &mut [MaybeUninit<T>]) -> *mut T {
this as *mut [MaybeUninit<T>] as *mut T
}
```
I changed some of the existing code to use array-of-`MaybeUninit` instead of `MaybeUninit`-of-array, successfully removing raw pointer casts there as well.
bors [Mon, 28 Jan 2019 14:12:15 +0000 (14:12 +0000)]
Auto merge of #55704 - Nemo157:pinned-generators, r=Zoxc
Use pinning for generators to make trait safe
I'm unsure whether there needs to be any changes to the actual generator transform. Tests are passing so the fact that `Pin<&mut T>` is fundamentally the same as `&mut T` seems to allow it to still work, but maybe there's something subtle here that could go wrong.
This is specified in [RFC 2349 § Immovable generators](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md#immovable-generators) (although, since that RFC it has become safe to create an immovable generator, and instead it's unsafe to resume any generator; with these changes both are now safe and instead the unsafety is moved to creating a `Pin<&mut [static generator]>` which there are safe APIs for).
bors [Mon, 28 Jan 2019 09:52:31 +0000 (09:52 +0000)]
Auto merge of #57899 - davidtwco:issue-56685, r=estebank
Unused variable suggestions apply on all patterns.
Fixes #56685.
This PR extends existing suggestions to prefix unused variable bindings in match arms with an underscore so that it applies to all patterns in a match arm.
r? @estebank
cc @alexcrichton (since you filed the issue)
David Wood [Fri, 25 Jan 2019 15:56:27 +0000 (16:56 +0100)]
Unused variable suggestions on all patterns.
This commit extends existing suggestions to prefix unused variable
bindings in match arms with an underscore so that it applies to all
patterns in a match arm.
bors [Mon, 28 Jan 2019 00:46:07 +0000 (00:46 +0000)]
Auto merge of #57442 - oli-obk:lazy_const, r=RalfJung
Simplify `ConstValue::ScalarPair`
While looking at #57432 I realized that some of our types for representing constants are very big. This reduces `LazyConst` to 3/4th of its original size and simplifies some code around slices at the same time.
bors [Sun, 27 Jan 2019 20:50:17 +0000 (20:50 +0000)]
Auto merge of #56932 - clarcharr:iter_refactor, r=Centril
Refactor core::iter module
A while back, I refactored `core::ops` in #42523 because the module had become a giant mess and was difficult to modify. Now, I'm doing the same with the `core::iter` module.
Like the `core::ops` refactor, things have been split up into multiple commits to make rebasing easier, and so that you can follow changes. Although the diffs are hard to decipher, the only actual code changes I've made in the first few commits are to modify exports and imports. I save all of the actual code refactoring, e.g. modifying what methods are called, for the end.
Rollup merge of #57764 - Xanewok:tiny-tweaks, r=nikomatsakis
Fix some minor warnings
Since apparently RLS works when initialized in the root repository (:tada:) I decided to fix some of the issues it caught.
There are a lot of unused attribute warnings left on `rustc_on_unimplemented` and `rustc_layout_scalar_valid_range_start` but I imagine we can't do much about it due to 2-stage compilation?
Mark Rousskov [Tue, 22 Jan 2019 00:47:57 +0000 (17:47 -0700)]
Workaround presence of LLVM library in stage0/lib
This commit works around the newly-introduced LLVM shared library.
This is needed such that llvm-config run from
librustc_llvm's build script can correctly locate it's own LLVM, not the
one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH
header within the llvm-config binary, which we want to use, but because
Cargo always adds the host compiler's "libdir" (stage0/lib in our
case) to the dynamic linker's search path, we weren't properly finding
the freshly-built LLVM in llvm/lib. By restoring the environment
variable setting the search path to what bootstrap sees, the problem is
resolved and librustc_llvm correctly links and finds the appropriate
LLVM.
Several run-make-fulldeps tests are also updated with similar handling.
bors [Sat, 26 Jan 2019 09:46:10 +0000 (09:46 +0000)]
Auto merge of #57425 - alexcrichton:stabilize-atomics, r=sfackler
std: Stabilize fixed-width integer atomics
This commit stabilizes the `Atomic{I,U}{8,16,32,64}` APIs in the
`std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753
and tracked in #32976 this feature has been unstable for quite some time
and is hopefully ready to go over the finish line now!
The API is being stabilized as-is. The API of `AtomicU8` and friends
mirrors that of `AtomicUsize`. A list of changes made here are:
* A portability documentation section has been added to describe the
current state of affairs.
* Emulation of smaller-size atomics with larger-size atomics has been
documented.
* As an added bonus, `ATOMIC_*_INIT` is now scheduled for deprecation
across the board in 1.34.0 now that `const` functions can be invoked
in statics.
Note that the 128-bit atomic types are omitted from this stabilization
explicitly. They have far less platform support than the other atomic
types, and will likely require further discussion about their best
location.
bors [Sat, 26 Jan 2019 07:08:18 +0000 (07:08 +0000)]
Auto merge of #55641 - nagisa:optimize-attr, r=pnkfelix
Implement optimize(size) and optimize(speed) attributes
This PR implements both `optimize(size)` and `optimize(speed)` attributes.
While the functionality itself works fine now, this PR is not yet complete: the code might be messy in places and, most importantly, the compiletest must be improved with functionality to run tests with custom optimization levels. Otherwise the new attribute cannot be tested properly. Oh, and not all of the RFC is implemented – attribute propagation is not implemented for example.
# TODO
* [x] Improve compiletest so that tests can be written;
* [x] Assign a proper error number (E9999 currently, no idea how to allocate a number properly);
* [ ] Perhaps reduce the duplication in LLVM attribute assignment code…
bors [Sat, 26 Jan 2019 02:10:15 +0000 (02:10 +0000)]
Auto merge of #57675 - cuviper:llvm-monorepo, r=alexcrichton
Rebase to the llvm-project monorepo
The new git submodule src/llvm-project is a monorepo replacing src/llvm
and src/tools/{clang,lld,lldb}. This also serves as a rebase for these
projects to the new 8.x branch from trunk.
The src/llvm-emscripten fork is unchanged for now.
Josh Stone [Wed, 16 Jan 2019 17:59:03 +0000 (09:59 -0800)]
Rebase to the llvm-project monorepo
The new git submodule src/llvm-project is a monorepo replacing src/llvm
and src/tools/{clang,lld,lldb}. This also serves as a rebase for these
projects to the new 8.x branch from trunk.
The src/llvm-emscripten fork is unchanged for now.
bors [Fri, 25 Jan 2019 23:27:20 +0000 (23:27 +0000)]
Auto merge of #57898 - Centril:rollup, r=Centril
Rollup of 5 pull requests
Successful merges:
- #56233 (Miri and miri-related code contains repetitions of `(n << amt) >> amt`)
- #57645 (distinguish "no data" from "heterogeneous" in ABI)
- #57734 (Fix evaluating trivial drop glue in constants)
- #57886 (Add suggestion for moving type declaration before associated type bindings in generic arguments.)
- #57890 (Fix wording in diagnostics page)
Alex Crichton [Mon, 7 Jan 2019 20:41:55 +0000 (12:41 -0800)]
std: Stabilize fixed-width integer atomics
This commit stabilizes the `Atomic{I,U}{8,16,32,64}` APIs in the
`std::sync::atomic` and `core::sync::atomic` modules. Proposed in #56753
and tracked in #32976 this feature has been unstable for quite some time
and is hopefully ready to go over the finish line now!
The API is being stabilized as-is. The API of `AtomicU8` and friends
mirrors that of `AtomicUsize`. A list of changes made here are:
* A portability documentation section has been added to describe the
current state of affairs.
* Emulation of smaller-size atomics with larger-size atomics has been
documented.
* As an added bonus, `ATOMIC_*_INIT` is now scheduled for deprecation
across the board in 1.34.0 now that `const` functions can be invoked
in statics.
Note that the 128-bit atomic types are omitted from this stabilization
explicitly. They have far less platform support than the other atomic
types, and will likely require further discussion about their best
location.
Rollup merge of #57734 - oli-obk:fixes_and_cleanups, r=pnkfelix
Fix evaluating trivial drop glue in constants
```rust
struct A;
impl Drop for A {
fn drop(&mut self) {}
}
const FOO: Option<A> = None;
const BAR: () = (FOO, ()).1;
```
was erroring with
```
error: any use of this value will cause an error
--> src/lib.rs:9:1
|
9 | const BAR: () = (FOO, ()).1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^-^
| |
| calling non-const function `std::ptr::real_drop_in_place::<(std::option::Option<A>, ())> - shim(Some((std::option::Option<A>, ())))`
|
= note: #[deny(const_err)] on by default
error: aborting due to previous error
```
before this PR. According to godbolt this last compiled successfully in 1.27
bors [Fri, 25 Jan 2019 14:25:37 +0000 (14:25 +0000)]
Auto merge of #57714 - matthewjasper:wellformed-unreachable, r=pnkfelix
[NLL] Clean up handling of type annotations
* Renames (Canonical)?UserTypeAnnotation -> (Canonical)?UserType so that the name CanonicalUserTypeAnnotation is free.
* Keep the inferred type associated to user type annotations in the MIR, so that it can be compared against the annotated type, even when the annotated expression gets removed from the MIR. (#54943)
* Use the inferred type to allow infallible handling of user type projections (#57531)
* Uses revisions for the tests in #56993
* Check the types of `Unevaluated` constants with no annotations (#46702)
* Some drive-by cleanup
Closes #46702
Closes #54943
Closes #57531
Closes #57731
cc #56993 leaving this open to track the underlying issue: we are not running tests with full NLL enabled on CI at the moment
bors [Fri, 25 Jan 2019 11:25:14 +0000 (11:25 +0000)]
Auto merge of #57891 - michaelwoerister:no-default-incr-bootstrap, r=pietroalbini
bootstrap: Don't rely on any default settings regarding incr. comp. in Cargo
https://github.com/rust-lang/cargo/pull/6564 (temporarily) makes incremental compilation the default for release builds. We don't want this default to apply to building the compiler itself, that is, `bootstrap`'s `incremental` flag should always be respected. Otherwise we'll get incrementally build releases, which we really don't want `:)`.
r? @Mark-Simulacrum
Anybody else from @rust-lang/release should feel free to r+ this too if they get around to it earlier.
David Wood [Thu, 24 Jan 2019 22:24:58 +0000 (23:24 +0100)]
Suggestion moving types before associated types.
This commit extends existing suggestions to move lifetimes before types
in generic arguments to also suggest moving types behind associated type
bindings.
Changes:
````
Rustup
allow assertions_on_constants for collapsible_if and missing_test_files
Improving comments.
Added rustfix to the test.
Improve span shortening.
Added "make_return" and "blockify" convenience methods in Sugg and used them in "needless_bool".
Fixed potential mistakes with nesting. Added tests.
Fix automatic suggestion on `use_self`.
run ./util/dev update_lints
add assert(true/false, some message) tests
change assert_checks to assertions_on_constants
run ./util/dev update_lints
Add unreachable!() as option
Add assert(true) and assert(false) lints
````
projects / rust.git / log