Updating documentation and version #26
Conversation
src/projection.rs
Outdated
| unsafe { | ||
| $crate::core_reexport::pin::Pin::map_unchecked_mut( | ||
| ::core::pin::Pin::map_unchecked_mut( |
There was a problem hiding this comment.
I don't think these changes ($crate::core_reexport -> ::core) are necessary. (iirc, $crate::core_reexport is a little more powerful than ::core, and futures crate prefers this pattern.)
There was a problem hiding this comment.
I reverted the changes, I'd like to know how is it more powerful ?
There was a problem hiding this comment.
I'd like to know how is it more powerful ?
::core may cause a compile error or call the wrong type if another crate that named 'core' exists.
$crate refers to the defined crate, so it will work correctly even if the name of core or pin-utils is changed or overwritten name with another crate.
For example, if we make the following changes to the first commit of this PR,
diff --git a/tests/stack_pin.rs b/tests/stack_pin.rs
index 4b6758d..d279908 100644
--- a/tests/stack_pin.rs
+++ b/tests/stack_pin.rs
@@ -1,7 +1,9 @@
#![forbid(unsafe_code)] // pin_mut! is completely safe.
+extern crate alloc as core;
+
use pin_utils::pin_mut;
-use core::pin::Pin;
+use std::pin::Pin;
#[test]
fn stack_pin() {We will get an error.
error[E0433]: failed to resolve: could not find `pin` in `core`
--> tests/stack_pin.rs:12:5
|
12 | pin_mut!(foo);
| ^^^^^^^^^^^^^^ could not find `pin` in `core`
|
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)Actually I think this should rarely be necessary, but a macro in this crate is re-exported by futures, so I think it would be preferable to support this like futures.
There was a problem hiding this comment.
Ok thank you for the explaination !
hyyking
changed the title
|
Ping - futures 0.3 still depends on an alpha of pin-utils, which is kind of weird. |
|
any news on this? I am working on packaging/updating futures + reverse dependencies for Debian, and this would be the only alpha crate in the whole big pile of crates to package ;) |
|
is this crate still maintained? |
|
cc @cramertj I would like to deprecate unsafe projection macros in the future as there are already safe alternatives (1, 2). but I think it is reasonable to release 0.1 as is, as futures and other crates still depend on it. (btw, I would be happy to help with the maintenance of this crate if help is needed.) |
|
Sorry for not seeing this, y'all-- I apparently don't have my notifications set up so that I can see new issues here unless I get cc'd. @taiki-e your help is always greatly appreciated 👍 That aside, this change looks fine to me-- I'll get a release out now. |
|
@cramertj: Thanks for the new release! (btw, the invitation seemed to be invalid because the repo moved. Could you send the invitation again?) |
|
Sadly I'm no longer an admin-- I just have write permissions, as do all members of https://github.com/orgs/rust-lang/teams/wg-async-foundations/members. I think you certainly deserve to be a member of that group, but I'm not sure how to go about that. Perhaps @Mark-Simulacrum knows? |
199: Support overwriting the name of core crate r=taiki-e a=taiki-e See rust-lang/pin-utils#26 (comment) Note: If the proc-macro does not depend on its own items, it may be preferable not to support overwriting the name of core/std crate for compatibility with reexport. Co-authored-by: Taiki Endo <te316e89@gmail.com>
0.1.0 release candidate for rust 1.39