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

Stabilize `Rc`, `Arc` and `Pin` as method receivers #56805

Merged
merged 3 commits into from Dec 22, 2018

Conversation

Projects
None yet
6 participants
@mikeyhew
Copy link
Contributor

mikeyhew commented Dec 14, 2018

Replaces #55880
Closes #55786
r? @nikomatsakis
cc @withoutboats @cramertj

This lets you write methods using self: Rc<Self>, self: Arc<Self>, self: Pin<&mut Self>, self: Pin<Box<Self>, and other combinations involving Pin and another stdlib receiver type, without needing the arbitrary_self_types. Other user-created receiver types can be used, but they still require the feature flag to use.

This is implemented by introducing a new trait, Receiver, which the method receiver's type must implement if the arbitrary_self_types feature is not enabled. To keep composed receiver types such as &Arc<Self> unstable, the receiver type is also required to implement Deref<Target=Self> when the feature flag is not enabled.

This lets you use self: Rc<Self> and self: Arc<Self> in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. self: Pin<&Self> and other pinned receiver types do not require the arbitrary_self_types feature, but they cannot be used on stable because Pin still requires the pin feature.

@nikomatsakis
Copy link
Contributor

nikomatsakis left a comment

Looks good to me. One nit, then r=me.

return false
}

let deref_trait_def_id = match fcx.tcx.lang_items().deref_trait() {

This comment has been minimized.

@nikomatsakis

nikomatsakis Dec 14, 2018

Contributor

It'd be nice to have some comments here, to document what we are requiring and why (basically what's in your PR comment).

This comment has been minimized.

@nikomatsakis

nikomatsakis Dec 14, 2018

Contributor

This can reference the doc comment on the fn itself I guess.

@mikeyhew

This comment has been minimized.

Copy link
Contributor

mikeyhew commented Dec 18, 2018

@nikomatsakis assuming this passes CI, it should be good to go

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Dec 18, 2018

@bors r=nikomatsakis

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 18, 2018

📌 Commit 603175f has been approved by nikomatsakis

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 20, 2018

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

mikeyhew added some commits Nov 20, 2018

Stabilize `Rc`, `Arc` and `Pin` as method receivers
This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.

This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.

This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
Refactor and add comments to code in receiver_is_valid
also updated some error messages

removed the code manually checking for `receiver_ty: Deref<Target=self_ty>`, in favour of using autoderef but only doing one iteration. This will cause error messages to be more consistent. Before, a "mismatched method receiver" error would be emitted when `receiver_ty` was valid except for a lifetime parameter, but only when `feature(arbitrary_self_types)` was enabled, and without the feature flag the error would be "uncoercible receiver". Now it emits "mismatched method receiver" in both cases.

@mikeyhew mikeyhew force-pushed the mikeyhew:stabilize-pin-as-receiver branch from 603175f to 286503a Dec 20, 2018

@mikeyhew

This comment has been minimized.

Copy link
Contributor

mikeyhew commented Dec 20, 2018

This is good to go again.

@cramertj

This comment has been minimized.

Copy link
Member

cramertj commented Dec 20, 2018

@bors r=nikomatsakis

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 20, 2018

📌 Commit 286503a has been approved by nikomatsakis

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 20, 2018

⌛️ Testing commit 286503a with merge 37ab3e6...

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

Auto merge of #56805 - mikeyhew:stabilize-pin-as-receiver, r=nikomats…
…akis

Stabilize `Rc`, `Arc` and `Pin` as method receivers

Replaces #55880
Closes  #55786
r? @nikomatsakis
cc @withoutboats @cramertj

This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.

This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.

This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 20, 2018

💔 Test failed - status-travis

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Dec 20, 2018

The job x86_64-gnu-distcheck 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.
[00:03:47]    Compiling cargo v0.32.0
[00:03:54] error[E0308]: mismatched types
[00:03:54]  --> /cargo/registry/src/github.com-1ecc6299db9ec823/cargo-0.32.0/src/cargo/util/sha256.rs:9:34
[00:03:54]   |
[00:03:54] 9 |         let hasher = Hasher::new(Algorithm::SHA256);
[00:03:54]   |                                  |
[00:03:54]   |                                  |
[00:03:54]   |                                  expected reference, found enum `util::sha256::crypto_hash::Algorithm`
[00:03:54]   |                                  help: consider borrowing here: `&Algorithm::SHA256`
[00:03:54]   |
[00:03:54]   = note: expected type `&util::sha256::crypto_hash::Algorithm`
[00:03:54]              found type `util::sha256::crypto_hash::Algorithm`
[00:03:54] error: aborting due to previous error
[00:03:54] 
[00:03:54] For more information about this error, try `rustc --explain E0308`.
[00:03:54] For more information about this error, try `rustc --explain E0308`.
[00:03:54] error: failed to compile `cargo-vendor v0.1.22`, intermediate artifacts can be found at `/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools`
[00:03:54] Caused by:
[00:03:54]   Could not compile `cargo`.
[00:03:54] 
[00:03:54] To learn more, run the command again with --verbose.
[00:03:54] To learn more, run the command again with --verbose.
[00:03:54] 
[00:03:54] 
[00:03:54] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "install" "-j" "4" "--locked" "--color" "always" "--force" "--debug" "--vers" "0.1.22" "cargo-vendor"
[00:03:54] 
[00:03:54] 
[00:03:54] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test distcheck
[00:03:54] Build completed unsuccessfully in 0:01:35
---
travis_time:end:14329584:start=1545332461225148456,finish=1545332461233051499,duration=7903043
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:24badd88
$ 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:0662e327
travis_time:start:0662e327
$ 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:0462256e
$ 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)

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Dec 20, 2018

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 21, 2018

⌛️ Testing commit 286503a with merge 64cb299...

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

Auto merge of #56805 - mikeyhew:stabilize-pin-as-receiver, r=nikomats…
…akis

Stabilize `Rc`, `Arc` and `Pin` as method receivers

Replaces #55880
Closes  #55786
r? @nikomatsakis
cc @withoutboats @cramertj

This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.

This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.

This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 21, 2018

💔 Test failed - status-travis

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Dec 21, 2018

The job dist-x86_64-linux 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.
[02:58:21] [ 46%] Building CXX object lib/IR/CMakeFiles/LLVMCore.dir/Instruction.cpp.o
[02:58:32] [ 46%] Building CXX object lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/DeadMachineInstructionElim.cpp.o
[02:58:42] [ 46%] Building CXX object lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/DebugLocStream.cpp.o

Broadcast message from root@travis-job-3fdf3aa9-85be-4ce0-8bb9-67e639ddc737
 (unknown) at 9:25 ...
The system is going down for power off NOW!

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 21, 2018

@bors retry

[02:58:21] [ 46%] Building CXX object lib/IR/CMakeFiles/LLVMCore.dir/Instruction.cpp.o
[02:58:32] [ 46%] Building CXX object lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/DeadMachineInstructionElim.cpp.o
[02:58:42] [ 46%] Building CXX object lib/CodeGen/AsmPrinter/CMakeFiles/LLVMAsmPrinter.dir/DebugLocStream.cpp.o

Broadcast message from root@travis-job-3fdf3aa9-85be-4ce0-8bb9-67e639ddc737
 (unknown) at 9:25 ...
The system is going down for power off NOW!

:(

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 22, 2018

⌛️ Testing commit 286503a with merge abaa934...

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

Auto merge of #56805 - mikeyhew:stabilize-pin-as-receiver, r=nikomats…
…akis

Stabilize `Rc`, `Arc` and `Pin` as method receivers

Replaces #55880
Closes  #55786
r? @nikomatsakis
cc @withoutboats @cramertj

This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.

This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.

This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Dec 22, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing abaa934 to master...

@bors bors merged commit 286503a into rust-lang:master Dec 22, 2018

2 checks passed

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

This was referenced Dec 22, 2018

@mikeyhew mikeyhew referenced this pull request Dec 24, 2018

Open

Tracking issue for `arbitrary_self_types` #44874

0 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment