Rename pointer field on Pin

[LegionMammal978]

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 #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.

[LegionMammal978]

@rustbot label +T-libs-api -T-libs

[bors]

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

[Amanieu]

@bors r+

[bors]

📌 Commit 985402d has been approved by Amanieu

It is now in the queue for this repository.

[matthiaskrgr]

@bors r-
I think this failed in #119755 (comment)

[LegionMammal978]

I've updated the expression in src/etc/natvis/libcore.natvis to account for the change in field name. I believe it should work, but I'm not able to test it with my current setup. Anyway, I've been thinking it might be better to hold off on merging this PR until #119615 is resolved one way or another, since that PR would then also have to revert this PR, and all the tests would have been touched for nothing.

[bors]

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

[dtolnay]

@bors r=Amanieu,dtolnay

[bors]

📌 Commit bc3fb52 has been approved by Amanieu,dtolnay

It is now in the queue for this repository.

[LegionMammal978]

@dtolnay Has #119615 been decided against? As I said earlier, I'd like to avoid needless reverts in the near future if that ends up as the solution.

[dtolnay]

I am personally on board with #119615, but it has been waiting 2 weeks for feedback from petrochenkov, and I don't think it makes sense to block this fix on that. Inserting a revert into that PR later is not a big deal.