New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pin stabilization #56939

Merged
merged 5 commits into from Dec 24, 2018

Conversation

Projects
None yet
@cramertj
Copy link
Member

cramertj commented Dec 18, 2018

This implements the changes suggested in #55766 (comment) and stabilizes the pin feature. @alexcrichton also listed several "blockers" in that issue, but then in this comment mentioned that they're more "TODO items":

In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above).

Let's settle these last bits here and get this thing stabilized! :)

r? @alexcrichton
cc @withoutboats

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Dec 18, 2018

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:05a20520:start=1545099560596306402,finish=1545099561662433965,duration=1066127563
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:56:29] 
[00:56:29] running 119 tests
[00:56:53] .iiiii...i.....i..i...i..i.i..i.ii..i.....i..i....i..........iiii.........i.i...ii...i.......ii.i.i. 100/119
[00:56:57] i......iii.i.....ii
[00:56:57] 
[00:56:57]  finished in 28.026
[00:56:57] travis_fold:end:test_debuginfo

---
[01:09:23] ......iiiii......................................................................................... 100/2218
[01:09:34] .................................................................................................... 200/2218
[01:09:48] .................................................................................................... 300/2218
[01:10:02] .....................................................i.............................................. 400/2218
[01:10:12] ...........................F........................................................................ 500/2218
[01:10:35] .................................................................................................... 700/2218
[01:10:46] .................................................................................................... 800/2218
[01:10:57] .................................................................................................... 900/2218
[01:11:08] .................................................................................................... 1000/2218
---
[01:12:15] .................................................................................................... 1600/2218
[01:12:27] .................................................................................................... 1700/2218
[01:12:39] .................................................................................................... 1800/2218
[01:12:51] .................................................................................................... 1900/2218
[01:13:03] .........F.......................................................................................... 2000/2218
[01:13:35] ..................
[01:13:35] failures:
[01:13:35] 
[01:13:35] ---- marker.rs - marker::Unpin (line 623) stdout ----
[01:13:35] ---- marker.rs - marker::Unpin (line 623) stdout ----
[01:13:35] error: the feature `pin` has been stable since 1.33.0 and no longer requires an attribute to enable
[01:13:35]  --> marker.rs:623:12
[01:13:35] 3 | #![feature(pin)]
[01:13:35]   |            ^^^
[01:13:35]   |
[01:13:35] note: lint level defined here
---
[01:13:35] 
[01:13:35] thread 'marker.rs - marker::Unpin (line 623)' panicked at 'couldn't compile the test', src/librustdoc/test.rs:326:13
[01:13:35] note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[01:13:35] 
[01:13:35] ---- pin.rs - pin (line 45) stdout ----
[01:13:35] error[E0599]: no function or associated item named `get_mut_unchecked` found for type `std::pin::Pin<_>` in the current scope
[01:13:35]   --> pin.rs:81:13
[01:13:35]    |
[01:13:35] 39 |             Pin::get_mut_unchecked(mut_ref).slice = slice;
[01:13:35]    |             ^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `std::pin::Pin<_>`
[01:13:35] 
[01:13:35] thread 'pin.rs - pin (line 45)' panicked at 'couldn't compile the test', src/librustdoc/test.rs:326:13
[01:13:35] 
[01:13:35] failures:
[01:13:35]     marker.rs - marker::Unpin (line 623)
[01:13:35]     pin.rs - pin (line 45)
---
183724 ./obj/build/x86_64-unknown-linux-gnu/test/ui
160388 ./obj/build/bootstrap/debug/incremental
153292 ./src/tools/clang
144288 ./obj/build/bootstrap/debug/incremental/bootstrap-2x7szixskz2uj
144284 ./obj/build/bootstrap/debug/incremental/bootstrap-2x7szixskz2uj/s-f7owzz0jdy-pxvx5k-2sxk29axi4qzn
137420 ./obj/build/x86_64-unknown-linux-gnu/stage1-rustc
128696 ./obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu
128692 ./obj/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release
126304 ./obj/build/x86_64-unknown-linux-gnu/stage1-rust

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@alexcrichton
Copy link
Member

alexcrichton left a comment

👍

Looks like there's some CI doctest failures too? When this is CI-green I'd ideally like to do a crater run just to be double-sure that the addition of Unpin as a name to the prelude doesn't cause any unintended fallout.

Show resolved Hide resolved src/liballoc/boxed.rs Outdated
Show resolved Hide resolved src/libcore/option.rs
#[inline(always)]
pub unsafe fn new_unchecked(pointer: P) -> Pin<P> {
Pin { pointer }
}

/// Get a pinned shared reference from this pinned pointer.
#[unstable(feature = "pin", issue = "49150")]
#[stable(feature = "pin", since = "1.33.0")]
#[inline(always)]
pub fn as_ref(self: &Pin<P>) -> Pin<&P::Target> {

This comment has been minimized.

@alexcrichton

alexcrichton Dec 18, 2018

Member

I talked with @withoutboats in person about this a bit as I was slightly concerned about this, so I just wanted to make sure to write down some thoughts. The AsRef trait is the libs team's worst offender in terms of "thorns in our side about backwards compatibility", as adding AsRef anywhere seems to break due to subtle inference changes.

Along those lines, I think it definitely makes sense to be consistent with self vs not in Pin, but I just wanted to raise this and make sure it'd been considered. I think @withoutboats mentioned they'd talk with you @cramertj about the ergonomic importance of self-vs-not. It seems like the primary motivation for self everywhere was ergonomics, and I'd just want to make sure it's well motivated to take such a common name like as_ref!

Concretely my worry is that we may not be able to add inherent self-based methods to Pin in the future if they cause too much breakage in the ecosystem (due to shadowing conflicts), which would cause us to have two idioms.

Again though, just wanted to make sure I brought that up and ensure it was weighed!

This comment has been minimized.

@cramertj

cramertj Dec 18, 2018

Member

The ergonomic improvement from self in as_mut and set at least are pretty important because it's common to see them chained, which gets pretty ugly otherwise. The most common instance of this is Pin::get_mut_unchecked(Pin::as_mut(self)) inside futures-rs (it's pretty common to see Pin::as_mut used for reborrowing in combination with other methods). set is another one where I personally just get it wrong every time and try to spell it self.set(value) rather than Pin::set(Pin::as_mut(self), value);-- I think you can probably see why ;).

I'm totally sympathetic to the concerns here and am interested in any ideas you might have for making this easier. One thing I will say is that I think it's much more common to call Pin methods on a Pin<P<T>> than it is to call e.g. Rc methods on an Rc<T>, so I'd been using that to justify to myself why Pin was "different" in this respect.

This comment has been minimized.

@alexcrichton

alexcrichton Dec 18, 2018

Member

Ok sure thing, I just wanted to double-confirm. I agree that the usage pattern of Pin seems like it favors inherent methods more often is good motivation for breaking the norm.

This comment has been minimized.

@withoutboats

withoutboats Dec 18, 2018

Contributor

One thing @alexcrichton and I talked about was making only as_ref and as_mut associated functions, so you'd get Pin::as_mut(self).get_mut_uncheckedand so on. What would you think about that @cramertj?

This comment has been minimized.

@cramertj

cramertj Dec 18, 2018

Member

I'd probably want something not called as_mut that did reborrowing in that case. I can define it as a trait in the pin_utils crate or something, but that seems like it kind of defeats the purpose.

This comment has been minimized.

@cramertj

cramertj Dec 18, 2018

Member

(to be clear: I'm fine making this change if it's the one @rust-lang/libs wants, it's just much more ergonomic and easier to read the chained-method version)

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Dec 18, 2018

Before you r+ the stabilization, I'd like to get @aturon's views on what I wrote here.

@alexcrichton alexcrichton added the T-libs label Dec 18, 2018

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Dec 18, 2018

@Centril IIRC @aturon is out for the holidays until the new year. I'd be happy to discuss more w/ you if you'd like-- although I think you already know my view 😄

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Dec 18, 2018

@bors: r+

I'm going to go ahead and approve this because we have plenty of time in the rest of the cycle to tweak and modify things, but I believe it's clear at this point we're not going to fundamentally change directions. While I won't pretend to speak for @aturon, @Centril I'm like 95% sure that @aturon wouldn't want to block this on figuring out &pin T.

I'm also gonna cc @rust-lang/libs on this as well, there's a few tweaks to the original issue (and the original issue is sort of massive). If any of y'all are interested but have reservations please feel free to comment and I can r- and we can discuss!

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 18, 2018

📌 Commit c3ab203 has been approved by alexcrichton

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Dec 18, 2018

@cramertj

@Centril IIRC @aturon is out for the holidays until the new year. I'd be happy to discuss more w/ you if you'd like-- although I think you already know my view 😄

Sure; Aaron is; You and me already discussed it plenty in private; but I'd like to hear from Aaron specifically so that I'm sure that our high level future plans are relatively in-sync.

@alexcrichton

I'm going to go ahead and approve this because we have plenty of time in the rest of the cycle to tweak and modify things, but I believe it's clear at this point we're not going to fundamentally change directions. While I won't pretend to speak for @aturon, @Centril I'm like 95% sure that @aturon wouldn't want to block this on figuring out &pin T.

I'm not saying we should change directions or that we should figure out &pin T now; just that we should ensure that our future plans are not diverging and from what Aaron said they seem to be right now. So I'm made uncomfortable by stabilizing right now since Future and async fn will rely on it. (by all means land the changes minus stabilization on nightly right now tho...)

I also don't think there's time pressure to do it now since 1.33 master=>beta promotion will happen on the 16th of January (T-2 from 18th of January) and Aaron should be back by then so I don't think it will risk missing 1.33 if we wait a bit.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Dec 18, 2018

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:006a4677:start=1545158523582730335,finish=1545158580677800628,duration=57095070293
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:53:48] 
[00:53:48] running 119 tests
[00:54:10] .iiiii...i.....i..i...i..i.i..i.ii..i.....i..i....i..........iiii.........i.i...ii...i.......ii.i.i. 100/119
[00:54:14] i......iii.i.....ii
[00:54:14] 
[00:54:14]  finished in 26.712
[00:54:14] travis_fold:end:test_debuginfo

---
[01:08:52] .................................................................................................... 1600/2218
[01:09:03] .................................................................................................... 1700/2218
[01:09:15] .................................................................................................... 1800/2218
[01:09:28] .................................................................................................... 1900/2218
[01:09:40] .........F.......................................................................................... 2000/2218
[01:10:09] .................................i.......................................................i.......... 2200/2218
Tue, 18 Dec 2018 19:53:22 GMT
travis_time:end:0452facc:start=1545162802702022970,finish=1545162802744076365,duration=42053395
The command "date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:2c26f2cf:start=1545162803779232971,finish=1545162803784376953,duration=5143982
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0a1e742d
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:15a94330
travis_time:start:15a94330
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:01113078
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@cramertj cramertj force-pushed the cramertj:pin-stabilization branch from c3ab203 to 9229488 Dec 18, 2018

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Dec 18, 2018

@Centril If you have specific concerns about the API and its interaction with &pin I'd be happy to chat more about those. I don't think we're going to change anything about the design here in response to those discussions-- if you disagree or see aspects of the API we're stabilizing you think we might want to revisit before this is stabilized in 1.33, feel free to raise them on the tracking issue.

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Dec 18, 2018

@bors r=alexcrichton

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 18, 2018

📌 Commit 9229488 has been approved by alexcrichton

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Dec 18, 2018

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:03420d2c:start=1545163607887865163,finish=1545163687189380861,duration=79301515698
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:53:12] 
[00:53:12] running 119 tests
[00:53:35] .iiiii...i.....i..i...i..i.i..i.ii..i.....i..i....i..........iiii.........i.i...ii...i.......ii.i.i. 100/119
[00:53:39] i......iii.i.....ii
[00:53:39] 
[00:53:39]  finished in 26.713
[00:53:39] travis_fold:end:test_debuginfo

---
[01:18:10] travis_fold:end:stage0-linkchecker

[01:18:10] travis_time:end:stage0-linkchecker:start=1545168384630372367,finish=1545168386735049222,duration=2104676855

[01:18:11] std/pin/index.html:23: broken link - std/pin/trait.Unpin.html
[01:18:13] core/pin/index.html:23: broken link - core/pin/trait.Unpin.html
[01:18:15] thread 'main' panicked at 'found some broken links', src/tools/linkchecker/main.rs:49:9
[01:18:15] 
[01:18:15] 
[01:18:15] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/linkchecker" "/checkout/obj/build/x86_64-unknown-linux-gnu/doc"
[01:18:15] expected success, got: exit code: 101
[01:18:15] expected success, got: exit code: 101
[01:18:15] 
[01:18:15] 
[01:18:15] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:18:15] Build completed unsuccessfully in 0:35:32
[01:18:15] Makefile:58: recipe for target 'check' failed
[01:18:15] make: *** [check] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0883cf00
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Tue Dec 18 21:26:32 UTC 2018

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Dec 19, 2018

@bors r=alexcrichton

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 19, 2018

📌 Commit 46a4ff6 has been approved by alexcrichton

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Dec 19, 2018

@Centril I can speak for @aturon somewhat, having spoken to him about this recently. This is my opinion which I understand him to agree with (I also understand his opinion to be that we should stabilize these APIs immediately).

The reality has always been that a type alias is not sufficient to backwards compatibly convert from library pins to language-supported pins, because replacing a struct with a type alias is not actually backwards compatible (because of things like destructuring exposing the reality). It's clear that if we wanted to add &pin, we'd need something more invasive to "coerce" the library type to the built in reference, regardless of what API we stabilize.

However, I also think its not very likely that we will directly add an &pin type, for these reasons:

  1. The main reason to do it is that it enables projection more ergonomically, but we've found that projection cannot be made into a safe operation in general, which weakens the motivation.
  2. The library API no longer involves a proliferation of types and is in fact more composable than the build in reference type, because it composes with library pointers like Pin<Box<T>> and Pin<Arc<T>>.
  3. Pin projections are only important for combinators which will rapidly become unidiomatic to write as async fn is stabilized and made available in traits. This would be adding a new pointer type for a very niche feature.
  4. We've found other examples, like shifgrethor, which encounter the same projection issues as pinning with their type. If we really wanted to solve this problem, we'd probably want to solve it through some kind of extensible API. None of us has a clear idea what that would look like, but it wouldn't be a hardcoded new reference type pin.

I think @aturon agrees with this, and his comment was worded somewhat poorly - he just meant that we can in the future add &pin if we decide we should (with backwards compatibility handled through some kind of lang item-y coercion-y hack), not that this API is intended to be a step on the inevitable road to pinned references.

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Dec 21, 2018

Rollup merge of rust-lang#56939 - cramertj:pin-stabilization, r=alexc…
…richton

Pin stabilization

This implements the changes suggested in rust-lang#55766 (comment) and stabilizes the `pin` feature. @alexcrichton also listed several "blockers" in that issue, but then in [this comment](rust-lang#55766 (comment)) mentioned that they're more "TODO items":
>  In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above).

Let's settle these last bits here and get this thing stabilized! :)

r? @alexcrichton
cc @withoutboats

bors added a commit that referenced this pull request Dec 21, 2018

Auto merge of #57022 - Mark-Simulacrum:rollup, r=Mark-Simulacrum
Rollup of 22 pull requests

Successful merges:

 - #55798 (Add version display for associated consts)
 - #56802 (Add DoubleEndedIterator::nth_back)
 - #56824 (rustdoc: display rustc_private APIs as "Internal")
 - #56862 (stop treating trait objects from #[fundamental] traits as fundamental)
 - #56887 (Disable field reordering for repr(int).)
 - #56892 (rustc: Update Clang used to build LLVM on Linux)
 - #56906 (Issue #56905)
 - #56914 (Ignore ui/target-feature-gate on sparc, sparc64, powerpc, powerpc64 and powerpc64le)
 - #56919 (Remove a wrong multiplier on relocation offset computation)
 - #56933 (Add --progress to git submodule commands in x.py)
 - #56939 (Pin stabilization)
 - #56941 (deny intra-doc link resolution failures in libstd)
 - #56953 (Mark tuple structs as live if their constructors are used)
 - #56954 (Add dist builder for Armv8-M Mainline)
 - #56970 (Mem uninit doc ptr drop)
 - #56973 (make basic CTFE tracing available on release builds)
 - #56979 (Adding unwinding support for x86_64_fortanix_unknown_sgx target.)
 - #56981 (miri: allocation is infallible)
 - #56984 (A few tweaks to dropck_outlives)
 - #56989 (Fix compiletest `trim` deprecation warnings)
 - #56992 (suggest similar lint names for unknown lints)
 - #57002 (Stabilize Vec(Deque)::resize_with)

Failed merges:

r? @ghost

Centril added a commit to Centril/rust that referenced this pull request Dec 22, 2018

Rollup merge of rust-lang#56939 - cramertj:pin-stabilization, r=alexc…
…richton

Pin stabilization

This implements the changes suggested in rust-lang#55766 (comment) and stabilizes the `pin` feature. @alexcrichton also listed several "blockers" in that issue, but then in [this comment](rust-lang#55766 (comment)) mentioned that they're more "TODO items":
>  In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above).

Let's settle these last bits here and get this thing stabilized! :)

r? @alexcrichton
cc @withoutboats
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 22, 2018

☔️ The latest upstream changes (presumably #56805) made this pull request unmergeable. Please resolve the merge conflicts.

cramertj added some commits Dec 18, 2018

Update Pin API to match the one proposed for stabilization
Remove pin::Unpin reexport and add Unpin to the prelude.
Change Pin associated functions to methods.
Rename get_mut_unchecked_ to get_unchecked_mut
Remove impl Unpin for Pin
Mark Pin repr(transparent)

@cramertj cramertj force-pushed the cramertj:pin-stabilization branch from 46a4ff6 to 861df06 Dec 22, 2018

@mikeyhew

This comment has been minimized.

Copy link
Contributor

mikeyhew commented Dec 22, 2018

Sorry, I noticed this was going to conflict with #56805, but didn't bother commenting because it was way farther behind in the queue. Didn't realize it might be included in a rollup.

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Dec 23, 2018

@bors r=alexcrichton

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 23, 2018

📌 Commit 861df06 has been approved by alexcrichton

Centril added a commit to Centril/rust that referenced this pull request Dec 23, 2018

Rollup merge of rust-lang#56939 - cramertj:pin-stabilization, r=alexc…
…richton

Pin stabilization

This implements the changes suggested in rust-lang#55766 (comment) and stabilizes the `pin` feature. @alexcrichton also listed several "blockers" in that issue, but then in [this comment](rust-lang#55766 (comment)) mentioned that they're more "TODO items":
>  In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above).

Let's settle these last bits here and get this thing stabilized! :)

r? @alexcrichton
cc @withoutboats

bors added a commit that referenced this pull request Dec 24, 2018

Auto merge of #57087 - Centril:rollup, r=Centril
Rollup of 14 pull requests

Successful merges:

 - #56188 (enum type instead of variant suggestion unification )
 - #56342 (Improve docs for collecting into `Option`s)
 - #56916 (Fix mutable references in `static mut`)
 - #56917 (Simplify MIR generation for logical operations)
 - #56939 (Pin stabilization)
 - #56953 (Mark tuple structs as live if their constructors are used)
 - #56964 (Remove `TokenStream::JointTree`.)
 - #56966 (Correct strings for raw pointer deref and array access suggestions)
 - #57020 (Point to cause of `fn` expected return type)
 - #57032 (fix deprecation warnings in liballoc benches)
 - #57053 (Fix alignment for array indexing)
 - #57062 (Fix a comment)
 - #57067 (Stabilize min_const_unsafe_fn in 1.33)
 - #57078 (Ignore two tests on s390x)

Failed merges:

r? @ghost

bors added a commit that referenced this pull request Dec 24, 2018

Auto merge of #57087 - Centril:rollup, r=Centril
Rollup of 14 pull requests

Successful merges:

 - #56188 (enum type instead of variant suggestion unification )
 - #56342 (Improve docs for collecting into `Option`s)
 - #56916 (Fix mutable references in `static mut`)
 - #56917 (Simplify MIR generation for logical operations)
 - #56939 (Pin stabilization)
 - #56953 (Mark tuple structs as live if their constructors are used)
 - #56964 (Remove `TokenStream::JointTree`.)
 - #56966 (Correct strings for raw pointer deref and array access suggestions)
 - #57020 (Point to cause of `fn` expected return type)
 - #57032 (fix deprecation warnings in liballoc benches)
 - #57053 (Fix alignment for array indexing)
 - #57062 (Fix a comment)
 - #57067 (Stabilize min_const_unsafe_fn in 1.33)
 - #57078 (Ignore two tests on s390x)

Failed merges:

r? @ghost

@mikeyhew mikeyhew referenced this pull request Dec 24, 2018

Open

Tracking issue for `arbitrary_self_types` #44874

0 of 3 tasks complete

@bors bors merged commit 861df06 into rust-lang:master Dec 24, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@cramertj cramertj deleted the cramertj:pin-stabilization branch Dec 26, 2018

@mikeyhew

This comment has been minimized.

Copy link
Contributor

mikeyhew commented Dec 27, 2018

I'm concerned about a couple of the method names here. Would it be possible to un-stabilize some of them or rename them before this hits stable? Specifically:

as_mut -> as_pin_mut
as_ref -> as_pin_ref
into_ref -> into_pin_ref

These methods all return pinned references, while their names suggest they return the bare reference, which is confusing. I also just think that 11 methods and associated functions is a lot to stabilize in one go, and it would be nice to do things more incrementally.

@glaebhoerl

This comment has been minimized.

Copy link
Contributor

glaebhoerl commented Dec 28, 2018

FWIW, I think that matches how e.g. Option::as_ref returns an Option<&T> not an &T, but I'm a big fan of this idea as a way to avoid autoderef issues in practice!

@Julius-Beides

This comment has been minimized.

Copy link

Julius-Beides commented Dec 28, 2018

It was really hard to understand what pinning does, largely because the term Unpin is everywhere, but it was hard to make sense of that term. My intuition sayed that Unpin means "undoing what Pin does", but that is not correct.

I suggest renaming Unpin to something more meaningful like PinNotNeeded or SafeWithoutPinning. (open for better suggestions).

(Do I understand this correctly?) Unpin can be defined as "Types where pinning is not necessary, or in other words, types which can be safely moved after being pinned."
Renaming would make things more clear:

/// Constructs a new `Pin<Box<T>>`. If `T` does not implement `PinNotNeeded`, then
/// `x` will be pinned in memory and unable to be moved.
pub fn pin(x: T) -> Pin<Box<T>> {
    (box x).into()
}

I hope my view as an outsider was helpful, although it is kind of late for the refactoring ^^

@glaebhoerl

This comment has been minimized.

Copy link
Contributor

glaebhoerl commented Dec 28, 2018

@Julius-Beides I happen to agree with your position, but this question was already debated at considerable length in #55766, which is linked from the original post here. Please try to be thorough in checking whether what you are about to propose has already been suggested!

@mikeyhew

This comment has been minimized.

Copy link
Contributor

mikeyhew commented Dec 28, 2018

@glaebhoerl I think that's different. Option also has methods called as_pin_ref and as_pin_mut that return Option<Pin<&T>> and Option<Pin<&mut T>>

@Julius-Beides

This comment has been minimized.

Copy link

Julius-Beides commented Dec 29, 2018

@glaebhoerl Thank you for your answer.
Aparrently I didn't notice any naming discussions after reading through the RFC and issues for an hour or two.

@mikeyhew

This comment has been minimized.

Copy link
Contributor

mikeyhew commented Dec 29, 2018

Option also has methods called as_pin_ref and as_pin_mut that return Option<Pin<&T>> and Option<Pin<&mut T>>

Actually, maybe that's why the names as_ref and as_mut were chosen — a method named as_pin_ref or as_pin_mut would probably conflict with Option's methods of the same name. @cramertj can you confirm?

@DutchGhost

This comment has been minimized.

Copy link

DutchGhost commented Jan 1, 2019

Not sure where to ask this, but has this 'issue' been fixed yet?: #56256

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment