Regression: issue #43941 (pointer methods) causes code in nvml crate to no longer compile

[raphaelcohn]

In this crate, there is an extension trait:-

pub trait PMEMblkpoolEx
{
...
    /// Returns false if the block has previously had its error condition set
	#[inline(always)]
	fn read(self, to: *mut c_void, zeroBasedBlockIndex: usize) -> bool;
...
}

This is then impl'd for an existing pointer:-

impl PMEMblkpoolEx for *mut PMEMblkpool
{
...
    
	#[inline(always)]
	fn read(self, to: *mut c_void, zeroBasedBlockIndex: usize) -> bool
	{
        ...
        }
...
}

Compiling this produces:-

error: use of unstable library feature 'pointer_methods' (see issue #43941)
  --> src/blockPool/BlockPool.rs:69:10
   |
69 |   self.0.read(to, zeroBasedBlockIndex)
   |          ^^^^
   |
   = help: add #![feature(pointer_methods)] to the crate attributes to enable

This is wrong on several levels. Firstly, adding a new feature to the std lib broke existing code. Secondly, the error message is decidedly incorrect. I'm actually in favour of the new pointer methods, so I'm happy to fix the code in this crate going forward (?would specialization help?), but I feel something got missed here in the implementation process. There's a decided lack of documentation around it - the unstable book contains no details, and the tracking issue is equally thin.

[eddyb]

I don't think anyone expected methods on raw pointers - they're almost useless in general.
That is, you always have to wrap them to write any kind of safe code involving data behind them (and sometimes even unsafe code needs wrapping to avoid even worse misuse).

OTOH, this should've been caught in the process, I wonder if it's nightly-only and we haven't ran crater for this release yet (but I'm unaware of the exact procedure here).
cc @rust-lang/libs

[alexcrichton]

This was most likely caused by #43964 where new inherent methods were added to raw pointers. It's definitely true though that the tracking issue is light on details!

I believe the PR in question has already made its way to stable (1.22.1) so there's not a huge sense of urgency to fix this per se, but would be good to discuss. We'll discuss this at a triage meeting for the libs team but it's pretty likely that we will leave the API as-is and won't change it.

[alexcrichton]

Ok I've brought this up with the @rust-lang/libs team during triage today and the conclusion was that we're going to stay the current course and close this issue. @raphaelcohn if you have difficulty updating though please just let us know!