Add a stack-pin!
-ning macro to core::pin
. by danielhenrymantilla · Pull Request #93176 · rust-lang/rust (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
This was referenced
Jan 21, 2022
Co-Authored-By: Mara Bos m-ou.se@m-ou.se
Since decl_macro
s and/or Span::def_site()
is deemed quite unstable,
no public-facing macro that relies on it can hope to be, itself, stabilized.
We circumvent the issue by no longer relying on field privacy for safety and,
instead, relying on an unstable feature-gate to act as the gate keeper for
non users of the macro (thanks to allow_internal_unstable
).
This is technically not correct (since a nightly
user could technically enable
the feature and cause unsoundness with it); or, in other words, this makes the
feature-gate used to gate the access to the field be (technically unsound, and
in practice) unsafe
. Hence it having unsafe
in its name.
Back to the macro, we go back to macro_rules!
/ mixed_site()
-span rules thanks
to declaring the decl_macro
as semitransparent
, which is a hack to basically have
pub macro_rules!
Co-Authored-By: Mara Bos m-ou.se@m-ou.se
This thus still makes it technically possible to enable the feature, and thus
to trigger UB without unsafe
, but this is fine since incomplete features are
known to be potentially unsound (labelled "may not be safe").
This follows from the discussion at rust-lang#93176 (comment)
bors added S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
bors mentioned this pull request
yvt added a commit to r3-os/r3 that referenced this pull request
est31 mentioned this pull request
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…, r=Amanieu
Rename pointer
field on Pin
A few days ago, I was helping another user create a self-referential type using PhantomPinned
. However, I noticed an odd behavior when I tried to access one of the type's fields via Pin
's Deref
impl:
use std::{marker::PhantomPinned, ptr};
struct Pinned {
data: i32,
pointer: *const i32,
_pin: PhantomPinned,
}
fn main() {
let mut b = Box::pin(Pinned {
data: 42,
pointer: ptr::null(),
_pin: PhantomPinned,
});
{
let pinned = unsafe { b.as_mut().get_unchecked_mut() };
pinned.pointer = &pinned.data;
}
println!("{}", unsafe { *b.pointer });
}
error[E0658]: use of unstable library feature 'unsafe_pin_internals'
--> <source>:19:30
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^
error[E0277]: `Pinned` doesn't implement `std::fmt::Display`
--> <source>:19:20
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^^^^^^^^^^^^^ `Pinned` cannot be formatted with the default formatter
|
= help: the trait `std::fmt::Display` is not implemented for `Pinned`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
Since the user named their field pointer
, it conflicts with the pointer
field on Pin
, which is public but unstable since Rust 1.60.0 with rust-lang#93176. On versions from 1.33.0 to 1.59.0, where the field on Pin
is private, this program compiles and prints 42
as expected.
To avoid this confusing behavior, this PR renames pointer
to __pointer
, so that it's less likely to conflict with a pointer
field on the underlying type, as accessed through the Deref
impl. This is technically a breaking change for anyone who names their field __pointer
on the inner type; if this is undesirable, it could be renamed to something more longwinded. It's also a nightly breaking change for any external users of unsafe_pin_internals
.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…, r=Amanieu,dtolnay
Rename pointer
field on Pin
A few days ago, I was helping another user create a self-referential type using PhantomPinned
. However, I noticed an odd behavior when I tried to access one of the type's fields via Pin
's Deref
impl:
use std::{marker::PhantomPinned, ptr};
struct Pinned {
data: i32,
pointer: *const i32,
_pin: PhantomPinned,
}
fn main() {
let mut b = Box::pin(Pinned {
data: 42,
pointer: ptr::null(),
_pin: PhantomPinned,
});
{
let pinned = unsafe { b.as_mut().get_unchecked_mut() };
pinned.pointer = &pinned.data;
}
println!("{}", unsafe { *b.pointer });
}
error[E0658]: use of unstable library feature 'unsafe_pin_internals'
--> <source>:19:30
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^
error[E0277]: `Pinned` doesn't implement `std::fmt::Display`
--> <source>:19:20
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^^^^^^^^^^^^^ `Pinned` cannot be formatted with the default formatter
|
= help: the trait `std::fmt::Display` is not implemented for `Pinned`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
Since the user named their field pointer
, it conflicts with the pointer
field on Pin
, which is public but unstable since Rust 1.60.0 with rust-lang#93176. On versions from 1.33.0 to 1.59.0, where the field on Pin
is private, this program compiles and prints 42
as expected.
To avoid this confusing behavior, this PR renames pointer
to __pointer
, so that it's less likely to conflict with a pointer
field on the underlying type, as accessed through the Deref
impl. This is technically a breaking change for anyone who names their field __pointer
on the inner type; if this is undesirable, it could be renamed to something more longwinded. It's also a nightly breaking change for any external users of unsafe_pin_internals
.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…, r=Amanieu,dtolnay
Rename pointer
field on Pin
A few days ago, I was helping another user create a self-referential type using PhantomPinned
. However, I noticed an odd behavior when I tried to access one of the type's fields via Pin
's Deref
impl:
use std::{marker::PhantomPinned, ptr};
struct Pinned {
data: i32,
pointer: *const i32,
_pin: PhantomPinned,
}
fn main() {
let mut b = Box::pin(Pinned {
data: 42,
pointer: ptr::null(),
_pin: PhantomPinned,
});
{
let pinned = unsafe { b.as_mut().get_unchecked_mut() };
pinned.pointer = &pinned.data;
}
println!("{}", unsafe { *b.pointer });
}
error[E0658]: use of unstable library feature 'unsafe_pin_internals'
--> <source>:19:30
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^
error[E0277]: `Pinned` doesn't implement `std::fmt::Display`
--> <source>:19:20
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^^^^^^^^^^^^^ `Pinned` cannot be formatted with the default formatter
|
= help: the trait `std::fmt::Display` is not implemented for `Pinned`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
Since the user named their field pointer
, it conflicts with the pointer
field on Pin
, which is public but unstable since Rust 1.60.0 with rust-lang#93176. On versions from 1.33.0 to 1.59.0, where the field on Pin
is private, this program compiles and prints 42
as expected.
To avoid this confusing behavior, this PR renames pointer
to __pointer
, so that it's less likely to conflict with a pointer
field on the underlying type, as accessed through the Deref
impl. This is technically a breaking change for anyone who names their field __pointer
on the inner type; if this is undesirable, it could be renamed to something more longwinded. It's also a nightly breaking change for any external users of unsafe_pin_internals
.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#119562 - LegionMammal978:rename-pin-pointer, r=Amanieu,dtolnay
Rename pointer
field on Pin
A few days ago, I was helping another user create a self-referential type using PhantomPinned
. However, I noticed an odd behavior when I tried to access one of the type's fields via Pin
's Deref
impl:
use std::{marker::PhantomPinned, ptr};
struct Pinned {
data: i32,
pointer: *const i32,
_pin: PhantomPinned,
}
fn main() {
let mut b = Box::pin(Pinned {
data: 42,
pointer: ptr::null(),
_pin: PhantomPinned,
});
{
let pinned = unsafe { b.as_mut().get_unchecked_mut() };
pinned.pointer = &pinned.data;
}
println!("{}", unsafe { *b.pointer });
}
error[E0658]: use of unstable library feature 'unsafe_pin_internals'
--> <source>:19:30
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^
error[E0277]: `Pinned` doesn't implement `std::fmt::Display`
--> <source>:19:20
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^^^^^^^^^^^^^ `Pinned` cannot be formatted with the default formatter
|
= help: the trait `std::fmt::Display` is not implemented for `Pinned`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
Since the user named their field pointer
, it conflicts with the pointer
field on Pin
, which is public but unstable since Rust 1.60.0 with rust-lang#93176. On versions from 1.33.0 to 1.59.0, where the field on Pin
is private, this program compiles and prints 42
as expected.
To avoid this confusing behavior, this PR renames pointer
to __pointer
, so that it's less likely to conflict with a pointer
field on the underlying type, as accessed through the Deref
impl. This is technically a breaking change for anyone who names their field __pointer
on the inner type; if this is undesirable, it could be renamed to something more longwinded. It's also a nightly breaking change for any external users of unsafe_pin_internals
.