regression: get_unchecked resolves to unstable feature use

[Mark-Simulacrum]

• https://crater-reports.s3.amazonaws.com/beta-1.47-1/beta-2020-08-29/reg/algebraics-0.2.0/log.txt

Unclear if this is a genuine regression or something else is going on, but seems like at least plausibly some change to resolution is involved.

[tesuji]

Bisect result: #73565

searched nightlies: from nightly-2020-04-01 to nightly-2020-09-07
regressed nightly: nightly-2020-08-22
searched commits: from e15510c to de521cb
regressed commit: d9d4d39

bisected with cargo-bisect-rustc v0.5.2

Host triple: x86_64-unknown-linux-musl
Reproduce with:

cargo bisect-rustc --start 2020-04-01 --target x86_64-unknown-linux-gnu --host x86_64-unknown-linux-gnu --verbose 

[Mark-Simulacrum]

Thanks @lzutao!

Looks like "get_unchecked is now an unstable, hidden method on Iterator" is the cause here, because it means downstream Iterator extensions cannot implement such a method (right?). This didn't cause too much breakage and it feels rare for such a method to be defined as an extension trait rather than inherently, so I'm personally fine with closing this as expected breakage.

It would be good to get an MCVE to get some idea of whether I'm correct here that inherent methods would still work on downstream iterators, and if so then I'm personally fine with closing this.

[tesuji]

MCVE: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d334cb2f4f0a985ddf674012a928abd3
Note: it is just an mvce and doesn't reflect what original code does.

// #![feature(trusted_random_access)]
pub struct Foo {
    x: usize,
    y: usize
}

impl Foo {
    fn get_unchecked(&self, x: usize, y: usize) -> (usize, usize) {
        unimplemented!()
    }
}
impl Iterator for Foo {
    type Item = (usize, usize);
    fn next(&mut self) -> Option<(usize, usize)> {
        Some(self.get_unchecked(self.x, self.y))
    }
}

[Dylan-DPC-zz]

Marking this as P-critical based on the wg-prioritization discussion

[spastorino]

Implemented this but @matthewjasper already has a solution too, so leaving it up to them and adjusting the assignee properly.

[spastorino]

Reopened to track backport of #77201

[spastorino]

Closing this one as #77201 was already backported.