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 }})

danielhenrymantilla

ibraheemdev

This was referenced

Jan 21, 2022

jfrimmel

@danielhenrymantilla @m-ou-se

Co-Authored-By: Mara Bos m-ou.se@m-ou.se

@danielhenrymantilla @m-ou-se

Since decl_macros 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

@danielhenrymantilla

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)

@danielhenrymantilla

m-ou-se

@m-ou-se

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

Feb 14, 2022

@bors bors mentioned this pull request

Feb 15, 2022

yvt added a commit to r3-os/r3 that referenced this pull request

Jun 18, 2022

@yvt

@est31 est31 mentioned this pull request

Mar 12, 2023

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request

Jan 8, 2024

@matthiaskrgr

…, 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

Jan 26, 2024

@matthiaskrgr

…, 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

Jan 26, 2024

@matthiaskrgr

…, 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

Jan 27, 2024

@rust-timer

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.