Skip to content
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
Merged

Pin stabilization #56939

merged 5 commits into from Dec 24, 2018

Conversation

@cramertj
Copy link
Member

@cramertj 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
Copy link
Collaborator

@rust-highfive 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)

Copy link
Member

@alexcrichton 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.

src/liballoc/boxed.rs Outdated Show resolved Hide resolved
src/libcore/option.rs Show resolved Hide resolved
#[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> {
Copy link
Member

@alexcrichton alexcrichton Dec 18, 2018

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!

Copy link
Member Author

@cramertj cramertj Dec 18, 2018

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.

Copy link
Member

@alexcrichton alexcrichton Dec 18, 2018

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.

Copy link
Contributor

@withoutboats withoutboats Dec 18, 2018

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?

Copy link
Member Author

@cramertj cramertj Dec 18, 2018

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.

Copy link
Member Author

@cramertj cramertj Dec 18, 2018

(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
Copy link
Contributor

@Centril Centril commented Dec 18, 2018

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

@cramertj
Copy link
Member Author

@cramertj 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
Copy link
Member

@alexcrichton 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
Copy link
Contributor

@bors bors commented Dec 18, 2018

📌 Commit c3ab203 has been approved by alexcrichton

@Centril
Copy link
Contributor

@Centril 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
Copy link
Collaborator

@rust-highfive 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 pin-stabilization branch from c3ab203 to 9229488 Dec 18, 2018
@cramertj
Copy link
Member Author

@cramertj 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
Copy link
Member Author

@cramertj cramertj commented Dec 18, 2018

@bors r=alexcrichton

@bors
Copy link
Contributor

@bors bors commented Dec 18, 2018

📌 Commit 9229488 has been approved by alexcrichton

@rust-highfive
Copy link
Collaborator

@rust-highfive 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
Copy link
Member Author

@cramertj cramertj commented Dec 19, 2018

@bors r=alexcrichton

@bors
Copy link
Contributor

@bors bors commented Dec 19, 2018

📌 Commit 46a4ff6 has been approved by alexcrichton

@withoutboats
Copy link
Contributor

@withoutboats 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 issue Dec 21, 2018
…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 issue Dec 21, 2018
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 issue Dec 22, 2018
…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
Copy link
Contributor

@bors bors commented Dec 22, 2018

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

@cramertj cramertj force-pushed the pin-stabilization branch from 46a4ff6 to 861df06 Dec 22, 2018
@mikeyhew
Copy link
Contributor

@mikeyhew 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
Copy link
Member Author

@cramertj cramertj commented Dec 23, 2018

@bors r=alexcrichton

@bors
Copy link
Contributor

@bors bors commented Dec 23, 2018

📌 Commit 861df06 has been approved by alexcrichton

Centril added a commit to Centril/rust that referenced this issue Dec 23, 2018
…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 issue Dec 24, 2018
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 issue Dec 24, 2018
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 bors merged commit 861df06 into rust-lang:master Dec 24, 2018
1 check passed
@cramertj cramertj deleted the pin-stabilization branch Dec 26, 2018
@mikeyhew
Copy link
Contributor

@mikeyhew 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
Copy link
Contributor

@glaebhoerl 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!

@Julian-Wollersberger
Copy link
Contributor

@Julian-Wollersberger Julian-Wollersberger 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
Copy link
Contributor

@glaebhoerl 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
Copy link
Contributor

@mikeyhew 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>>

@Julian-Wollersberger
Copy link
Contributor

@Julian-Wollersberger Julian-Wollersberger 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
Copy link
Contributor

@mikeyhew 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
Copy link
Contributor

@DutchGhost DutchGhost commented Jan 1, 2019

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

@Centril Centril added this to the 1.33 milestone Apr 26, 2019
jonhoo added a commit to jonhoo/rust that referenced this issue Feb 6, 2021
The `Unpin` bound was originally added in rust-lang#56939 following the
recommendation of @withoutboats in
rust-lang#55766 (comment)

That comment does not give explicit justification for why the bound
should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin
> impls: there is no pointer direction between `Pin<P>` and `P`. Its
> usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to
> change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is
sound (these days there is just an auto-impl for when `P: Unpin`). But,
I think the decision to also add the `Unpin` bound for `impl Future` may
have been unnecessary. Or if that's not the case, I'd be very interested
to have the argument for why written down somewhere. The bound _appears_
to not be needed, since the presence of a `Pin<P>` should indicate that
it's safe to project to `Pin<&mut P::Target>` just like for
`Pin::as_mut`.
jonhoo added a commit to jonhoo/rust that referenced this issue Feb 6, 2021
The `Unpin` bound was originally added in rust-lang#56939 following the
recommendation of @withoutboats in
rust-lang#55766 (comment)

That comment does not give explicit justification for why the bound
should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin
> impls: there is no pointer direction between `Pin<P>` and `P`. Its
> usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to
> change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is
sound (these days there is just an auto-impl for when `P: Unpin`). But,
I think the decision to also add the `Unpin` bound for `impl Future` may
have been unnecessary. Or if that's not the case, I'd be very interested
to have the argument for why written down somewhere. The bound _appears_
to not be needed, since the presence of a `Pin<P>` should indicate that
it's safe to project to `Pin<&mut P::Target>` just like for
`Pin::as_mut`.
JohnTitor pushed a commit to JohnTitor/rust that referenced this issue Jul 28, 2021
The `Unpin` bound was originally added in rust-lang#56939 following the
recommendation of @withoutboats in
rust-lang#55766 (comment)

That comment does not give explicit justification for why the bound
should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin
> impls: there is no pointer direction between `Pin<P>` and `P`. Its
> usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to
> change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is
sound (these days there is just an auto-impl for when `P: Unpin`). But,
I think the decision to also add the `Unpin` bound for `impl Future` may
have been unnecessary. Or if that's not the case, I'd be very interested
to have the argument for why written down somewhere. The bound _appears_
to not be needed, since the presence of a `Pin<P>` should indicate that
it's safe to project to `Pin<&mut P::Target>` just like for
`Pin::as_mut`.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jul 28, 2021
… r=m-ou-se

Remove P: Unpin bound on impl Future for Pin

We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly.

The `Unpin` bound was originally added in rust-lang#56939 following the recommendation of `@withoutboats` in rust-lang#55766 (comment)

That comment does not give explicit justification for why the bound should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jul 28, 2021
… r=m-ou-se

Remove P: Unpin bound on impl Future for Pin

We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly.

The `Unpin` bound was originally added in rust-lang#56939 following the recommendation of ``@withoutboats`` in rust-lang#55766 (comment)

That comment does not give explicit justification for why the bound should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet