bors [Wed, 20 Feb 2019 21:12:18 +0000 (21:12 +0000)]
Auto merge of #58056 - nikomatsakis:issue-57843-universe-leak, r=pnkfelix
make generalization code create new variables in correct universe
In our type inference system, when we "generalize" a type T to become
a suitable value for a type variable V, we sometimes wind up creating
new inference variables. So, for example, if we are making V be some
subtype of `&'X u32`, then we might instantiate V with `&'Y u32`.
This generalized type is then related `&'Y u32 <: &'X u32`, resulting
in a region constriant `'Y: 'X`. Previously, however, we were making
these fresh variables like `'Y` in the "current universe", but they
should be created in the universe of V. Moreover, we sometimes cheat
in an invariant context and avoid creating fresh variables if we know
the result must be equal -- we can only do that when the universes
work out.
kennytm [Tue, 19 Feb 2019 17:13:47 +0000 (01:13 +0800)]
Rollup merge of #58569 - kenta7777:reduce-code-repetition, r=oli-obk
Reduce Some Code Repetitions like `(n << amt) >> amt`
This Pull Request is related to [#49937](https://github.com/rust-lang/rust/issues/49937).
This Pull Request has reduced repetition of `(n << amt) >> amt`.
kennytm [Tue, 19 Feb 2019 17:13:44 +0000 (01:13 +0800)]
Rollup merge of #58565 - thomaseizinger:typo-future-docs, r=frewsxcv
Fix typo in std::future::Future docs
I am not quite sure if this is actually a typo but
1. to me the sentence doesn't make sense if it says "expect"
2. I hope that `Future`s are not really allowed to cause memory unsafety if they are polled after completion.
And a follow-up to https://github.com/rust-lang/rust/pull/54687, that started using IHLE in libcore.
Most of the changes in here fall into two big categories:
- Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop`, `Debug`, and `Clone`)
- Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`)
I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations [where the flipped one cannot elide the lifetime](https://internals.rust-lang.org/t/impl-type-parameter-aliases/9403/2?u=scottmcm).
I also removed two lifetimes that turned out to be completely unused; see https://github.com/rust-lang/rust/issues/41960#issuecomment-464557423
kennytm [Tue, 19 Feb 2019 17:13:36 +0000 (01:13 +0800)]
Rollup merge of #58551 - ssomers:master, r=oli-obk
Explain a panic in test case net::tcp::tests::double_bind
Those who try to build libstd on the Windows Subsystem for Linux experience a single failing test, where the point of failure is an explicit but anonymous panic, as reported in https://github.com/rust-lang/rust/issues/49367
This commit somewhat explains why and allows diagnosing a little.
kennytm [Tue, 19 Feb 2019 17:13:32 +0000 (01:13 +0800)]
Rollup merge of #58544 - TheBiggerGuy:rustc-doc-cli-args, r=TimNN
Fix doc for rustc "-g" flag
The rustc `-g` CLI flag was miss documented to be a synonym of `-C debug-level=2` and not `-C debuglevel=2`. Also add links to the codegen docs for each synonym.
I am unsure of this will conflict with work on #52938
These methods have been documented with reference to the original docs for `OsString`. @Mark-Simulacrum please let me know if you feel this does not suffice.
Further, I've not yet included tests for these definitions - please advise on how comprehensive tests need to be for methods such as these that simply alias other (already tested) methods.
kennytm [Tue, 19 Feb 2019 17:13:16 +0000 (01:13 +0800)]
Rollup merge of #58336 - GuillaumeGomez:fix-search-results-interactions, r=oli-obk
Fix search results interactions
The bug is visible when you search for "none": the second tab is empty and therefore it messes with the classes. Then when you try to use arrows on the third tab, it just crashes (because only 2 "search-results" are present and you're on tab 3).
kennytm [Tue, 19 Feb 2019 17:13:12 +0000 (01:13 +0800)]
Rollup merge of #56470 - llogiq:process-termination-doctest, r=GuillaumeGomez
Modify doctest's auto-`fn main()` to allow `Result`s
This lets the default `fn main()` ~~return `impl Termination`~~ unwrap Results, which allows the use of `?` in most tests without adding it manually. This fixes #56260
~~Blocked on `std::process::Termination` stabilization.~~
Using `Termination` would have been cleaner, but this should work OK.
bors [Mon, 18 Feb 2019 17:34:14 +0000 (17:34 +0000)]
Auto merge of #58549 - pietroalbini:fix-docker-ci-hash, r=Mark-Simulacrum
ci: fix docker cache hash collision
#58416 uncovered a bug in our caching for docker images: if the image `foo` pulls files from the image `bar` and a file in `bar` changed, the hash of `foo` will be the same even though it should be different. In that PR's case, `dist-i686-linux` pulls scripts from `dist-x86_64-linux`, and the PR only changed those scripts, causing an hash collision for `dist-i686-linux`.
We have to fix this, since the image will be rebuilt every time bors switches from testing master to testing beta/stable (and when it switches back), making CI way more painful than it currently is.
The approach used by this PR is to just include all the files in `src/ci/docker` in the hash. It's a bit heavy-handed and it will cause a rebuild of all the images every time a single image changes, but it's the best I can think of.
Pietro Albini [Sun, 17 Feb 2019 21:24:13 +0000 (22:24 +0100)]
ci: fix docker cache hash collision
Before this commit the hash used to cache docker images was calculated
from the image's files and the files in the scripts/ directory. This
worked fine when all the files used by an image were in those
directories, but some images pull files from other images, causing hash
collisions in some cases.
This commit changes the hash to include the files of all the docker
images, causing a rebuild of all the images when a single one changes.
That's a bit heavy-handed, but we have no way to track which files an
image pulls in and hash collisions are really painful to deal with.
bors [Mon, 18 Feb 2019 08:37:18 +0000 (08:37 +0000)]
Auto merge of #58541 - kennytm:fix-publish-toolstate-py-again, r=oli-obk
publish_toolstate.py: further fix the runtime errors
The regex was missing a `,`, causing `relevant_pr_match` to become None and set the PR number to -1 and assigned the new issue to `@<unknown user>`. This causes the 422 error when creating the issue due to invalid assignee and unable to leave the tool-is-broken comment since PR -1 does not exist.
The default user names are now also changed to @ghost to prevent the 422 error in case anything goes wrong again.
Scott McMurray [Mon, 18 Feb 2019 03:42:36 +0000 (19:42 -0800)]
Use more impl header lifetime elision
There are two big categories of changes in here
- Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`)
- Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`)
I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.
Aaron Stillwell [Sun, 17 Feb 2019 16:41:05 +0000 (16:41 +0000)]
Fixes for implementation of PathBuf methods (aliases for OsString)
- Fixed incorrect `mut` usage
- Fixed style in accordance with tidy
- Marked all methods as unstable
- Changed feature identifier to path_buf_alias_os_string_methods
kennytm [Sun, 17 Feb 2019 15:19:47 +0000 (23:19 +0800)]
publish_toolstate.py: further fix the runtime errors
The regex was missing a `,`, causing `relevant_pr_match` to become None
and set the PR number to -1 and assigned the new issue to
`@<unknown user>`. This causes the 422 error when creating the issue due
to invalid assignee and unable to leave the tool-is-broken comment since
PR -1 does not exist.
The default user names are now also changed to @ghost to prevent the
422 error in case anything goes wrong again.
bors [Sun, 17 Feb 2019 14:29:33 +0000 (14:29 +0000)]
Auto merge of #58416 - cuviper:dist-linux-gcc, r=alexcrichton
[CI] Update GCC in the dist-linux builders
Upstream LLVM is planning to raise their minimum toolchain requirements, so they may start using C++14 features. This new policy has already landed in the form of a "soft" error.
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130117.html
For GCC, they will require at least version 5.1. This PR moves our crosstool-ng builders to their max GCC 5.2, with a few small patches to fix compatibility. The dist-x86_64-linux builder is updated to GCC 5.5 and LLVM/Clang 8.0.0-rc2, which also affects dist-i686-linux sharing the same scripts.
kennytm [Fri, 15 Feb 2019 16:56:00 +0000 (00:56 +0800)]
Rollup merge of #58468 - RalfJung:maybe-uninit-split, r=Centril
split MaybeUninit into several features, expand docs a bit
This splits the `maybe_uninit` feature gate into several:
* `maybe_uninit` for what we will hopefully stabilize soon-ish.
* `maybe_uninit_ref` for creating references into `MaybeUninit`, for which the rules are not yet clear.
* `maybe_uninit_slice` for handling slices of `MaybeUninit`, which needs more API design work.
* `maybe_uninit_array` for creating arrays of `MaybeUninit` using a macro (because we don't have https://github.com/rust-lang/rust/issues/49147 yet).
Is that an okay thing to do? The goal is to help people avoid APIs we do not want to stabilize yet. I used this to make sure rustc itself does not use `get_ref` and `get_mut`.
I also extended the docs to advise against uninitialized integers -- again this is something for which the rules are still being discussed.
kennytm [Fri, 15 Feb 2019 16:55:59 +0000 (00:55 +0800)]
Rollup merge of #58448 - euclio:missing-summaries, r=QuietMisdreavus
rustdoc: mask `compiler_builtins` docs
Fixes #46783.
I wasn't able to fully confirm the underlying cause, but my theory is that functions in `compiler_builtins` were overwriting functions with the same names in libcore in the search index. Since the functions in `compiler_builtins` didn't have docs, that's why they weren't appearing in the results.
Masking the `compiler_builtins` crate fixes the search results. It appears that this crate was accidentally unmasked in #49503.
kennytm [Fri, 15 Feb 2019 16:55:56 +0000 (00:55 +0800)]
Rollup merge of #58438 - cuviper:posix_spawn_file_actions_addchdir_np, r=alexcrichton
Use posix_spawn_file_actions_addchdir_np when possible
This is a non-POSIX extension implemented in Solaris and in glibc 2.29.
With this we can still use `posix_spawn()` when `Command::current_dir()`
has been set, otherwise we fallback to `fork(); chdir(); exec()`.
kennytm [Fri, 15 Feb 2019 16:55:54 +0000 (00:55 +0800)]
Rollup merge of #58429 - RalfJung:box, r=TimNN
fix Box::into_unique effecitvely transmuting to a raw ptr
Miri/Stacked Borrows treat `Box` specially: they assert that it is unique, and tag it appropriately. However, currently, `Box::into_inner` is not aware of that and returns a raw pointer (wrapped in a `Unique`) that carries the same tag as the box, meaning it carries a `Uniq` tag. This leads to all sorts of problems when people use the raw pointer they get out of the `Unique` type.
In the future, it'd be interesting to make `Unique` also carry some kind of uniqueness. In that case, something like this would instead be needed whenever a raw pointer is extracted from a `Unique`. However, that is out-of-scope for the current version of Stacked Borrows. So until then, this changes `into_unique` to perform a proper reference-to-raw-ptr-cast, which clears the tag.
kennytm [Fri, 15 Feb 2019 16:55:49 +0000 (00:55 +0800)]
Rollup merge of #58196 - varkor:const-fn-feature-gate-error, r=oli-obk
Add specific feature gate error for const-unstable features
Before:
```
error: `impl Trait` in const fn is unstable
--> src/lib.rs:7:19
|
7 | const fn foo() -> impl T {
| ^^^^^^
error: aborting due to previous error
```
After:
```
error[E0723]: `impl Trait` in const fn is unstable (see issue #57563)
--> src/lib.rs:7:19
|
7 | const fn foo() -> impl T {
| ^^^^^^
= help: add #![feature(const_fn)] to the crate attributes to enable
error: aborting due to previous error
```
This improves the situation with https://github.com/rust-lang/rust/issues/57563. Fixes https://github.com/rust-lang/rust/issues/57544. Fixes https://github.com/rust-lang/rust/issues/54469.
kennytm [Fri, 15 Feb 2019 16:55:47 +0000 (00:55 +0800)]
Rollup merge of #58074 - scottmcm:stabilize-sort_by_cached_key, r=SimonSapin
Stabilize slice_sort_by_cached_key
I was going to ask on the tracking issue (https://github.com/rust-lang/rust/issues/34447), but decided to just send this and hope for an FCP here. The method was added last March by https://github.com/rust-lang/rust/pull/48639.
That's an identical signature to the existing `sort_by_key`, so I think the questions are just naming, implementation, and the usual "do we want this?".
The implementation seems to have proven its use in rustc at least, which many uses: https://github.com/rust-lang/rust/search?l=Rust&q=sort_by_cached_key
(I'm asking because it's exactly what I just needed the other day:
```rust
all_positions.sort_by_cached_key(|&n|
data::CITIES.iter()
.map(|x| *metric_closure.get_edge(n, x.pos).unwrap())
.sum::<usize>()
);
```
since caching that key is a pretty obviously good idea.)
projects / rust.git / log