bors [Fri, 22 Feb 2019 21:32:15 +0000 (21:32 +0000)]
Auto merge of #58644 - Centril:rollup, r=Centril
Rollup of 17 pull requests
Successful merges:
- #57656 (Deprecate the unstable Vec::resize_default)
- #58059 (deprecate before_exec in favor of unsafe pre_exec)
- #58064 (override `VecDeque::try_rfold`, also update iterator)
- #58198 (Suggest removing parentheses surrounding lifetimes)
- #58431 (fix overlapping references in BTree)
- #58555 (Add a note about 2018e if someone uses `try {` in 2015e)
- #58588 (remove a bit of dead code)
- #58589 (cleanup macro after 2018 transition)
- #58591 (Dedup a rustdoc diagnostic construction)
- #58600 (fix small documentation typo)
- #58601 (Search for target_triple.json only if builtin target not found)
- #58606 (Docs: put Future trait into spotlight)
- #58607 (Fixes #58586: Make E0505 erronous example fail for the 2018 edition)
- #58615 (miri: explain why we use static alignment in ref-to-place conversion)
- #58620 (introduce benchmarks of BTreeSet.intersection)
- #58621 (Update miri links)
- #58632 (Make std feature list sorted)
Rollup merge of #58620 - ssomers:btreeset_intersection_benchmarks, r=KodrAus
introduce benchmarks of BTreeSet.intersection
16 tests combining 4 kinds of contents with different sizes exposing edge cases.
The ones with asymmetric sizes are addressed by https://github.com/rust-lang/rust/pull/58577.
The pos_vs_neg cases seems (are were meant to be) the same as the neg_vs_pos case (same thing, reverse order) but reality shows a surprsing 25% difference.
Rollup merge of #58615 - RalfJung:ref-to-place-alignment, r=oli-obk
miri: explain why we use static alignment in ref-to-place conversion
@eddyb @oli-obk do you think this makes sense? Or should we use the run-time alignment (`align_of_val`)? I am a bit worried about custom DSTs, but that affects way more areas of Miri so I'd ignore them for now.
Rollup merge of #58607 - gurgalex:fail_E0505_for_2018_edition, r=matthewjasper
Fixes #58586: Make E0505 erronous example fail for the 2018 edition
The original example worked for 2015, but not the 2018 edition of Rust.
Borrowing the moved value after ownership is transferred seems required for 2018.
[this](https://github.com/rust-lang/rust/compare/rust-lang:f66e469...gurgalex:b2a02c8#diff-4ca866aea4a6efecd732f1975faaad88R1564) line though is correct for 2018, but not for the 2015 edition.
Rollup merge of #58606 - stjepang:put-future-into-spotlight, r=alexcrichton
Docs: put Future trait into spotlight
If a function returns a type that implements `Future`, there should be a small "i" symbol next to it indicating the return type implements an important trait.
Rollup merge of #58601 - gnzlbg:json_error, r=oli-obk
Search for target_triple.json only if builtin target not found
Before this commit, if the builtin target was found, but an error
happened when instantiating it (e.g. validating the target
specification file failed, etc.), then we ignored those errors
and proceeded to try to find a `target_triple.json` file, and if
that failed, reported that as an error.
With this commit, if rustc is supposed to provide the builtin target,
and something fails while instantiating it, that error will
get properly propagated.
Rollup merge of #58555 - scottmcm:try-2015, r=Centril
Add a note about 2018e if someone uses `try {` in 2015e
Inspired by https://github.com/rust-lang/rust/issues/58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.
What's the philosophy about gating for this? The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_. Let me know if I should do differently.
Rollup merge of #58431 - RalfJung:btree, r=Mark-Simulacrum
fix overlapping references in BTree
This fixes two kinds of overlapping references in BTree (both found by running the BTree test suite in Miri).
In `into_slices_mut`, we did `k.into_key_slice_mut()` followed by `self.into_val_slice_mut()` (where `k` is a copy of `self`). Calling `into_val_slice_mut` calls `self.len()`, which creates a shared reference to `NodeHeader`, which unfortunately (due to padding) overlaps with the mutable reference returned by `into_key_slice_mut`. Hence the key slice got (partially) invalidated. The fix is to avoid creating an `&NodeHeader` after the first slice got created.
In the iterators, we used to first create the references that will be returned, and then perform the walk on the tree. Walking the tree creates references (such as `&mut InternalNode`) that overlap with all of the keys and values stored in a pointer; in particular, they overlap with the references the iterator will later return. This is fixed by reordering the operations of walking the tree and obtaining the inner references.
The test suite still passes (and it passes in Miri now!), but there is a lot of code here that I do not understand...
bors [Thu, 21 Feb 2019 21:35:21 +0000 (21:35 +0000)]
Auto merge of #58592 - nikomatsakis:universe-leak-check, r=aturon
Re-implement leak check in terms of universes
This PR temporarily restores the leak-check, but implemented in terms of universes. This is not because the leak check behavior was necessarily **correct**, but because (a) we may want to have a transition period and because (b) we want to have more breathing room to work through the full implications of handling higher-ranked types correctly. Note that this PR builds atop https://github.com/rust-lang/rust/pull/58056.
Fixes #58451
Fixes #46989
Fixes #57639
r? @aturon
cc @arielb1, @lqd
~~Temporary note: I've not finished running `./x.py test` locally -- I'm confident a lot of error messages in tests will need updating. I sort of expect them to revert to the older, (imo) less good error messages, which is mildly unfortunate. There might be a way to preserve the new error messages, not sure.~~
bors [Thu, 21 Feb 2019 17:18:53 +0000 (17:18 +0000)]
Auto merge of #58584 - ehuss:update-cargo, r=alexcrichton
Update cargo
9 commits in 865cb70106a6b1171a500ff68f93ab52eea56e72..b33ce7fc9092962b0657b4c25354984b5e5c47e4
2019-02-10 15:49:37 +0000 to 2019-02-19 18:42:50 +0000
- Don't retry invalid credentials from git credential helpers (rust-lang/cargo#6681)
- Fix some typos in resolver tests (rust-lang/cargo#6682)
- Add an unstable option to build proc macros for both the host and the target (rust-lang/cargo#6547)
- Test cases proving RUSTC_WRAPPER can be a relative path (rust-lang/cargo#6638)
- Add support for Azure DevOps (rust-lang/cargo#6264)
- Update docs for removed `patch` restriction. (rust-lang/cargo#6663)
- Fix incorrect help message (rust-lang/cargo#6555)
- Stabilize Alternative Registries (rust-lang/cargo#6654)
- Having a [patch] section when publishing is not an error (rust-lang/cargo#6535)
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.
gnzlbg [Wed, 20 Feb 2019 17:08:21 +0000 (18:08 +0100)]
Search for target_triple.json only if builtin target not found
Before this commit, if the builtin target was found, but an error
happened when instantiating it (e.g. validating the target
specification file failed, etc.), then we ignored those errors
and proceeded to try to find a `target_triple.json` file, and if
that failed, reported that as an error.
With this commit, if rustc is supposed to provide the builtin target,
and something fails while instantiating it, that error will
get properly propagated.
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).