Dont check stability for items that are not pub to universe.

[pnkfelix]

Dont check stability for items that are not pub to universe.

In other words, skip it for private and even pub(restricted) items, because stability checks are only relevant to things visible in other crates.

Fix#38412.

[rust-highfive]

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

[pnkfelix]

Oops I left out a regression test.

(And it might be good to try to generalize the specific test to some other scenarios.... will do this in about two hours after i get through some meetings.)

[pnkfelix]

(weird, I guess I must have something subtly wrong with my check. Thank goodness for test suites.)

[nikomatsakis]

Marking as beta-accepted. Small patch, regression. cc @rust-lang/compiler

[eddyb]

I was hoping this could be used to skip the "missing annotation" error in the original crate, within this same file, ensuring that the logic is self-consistent.

[pnkfelix]

I'm not sure I follow.

The check you are referring to is fn check_missing_stability, right?

Is there an example you can show me of input code that is currently emitting a "missing annotation" error that you believe should be skipped via this check?

[arielb1]

test?

[pnkfelix]

@arielb1 okay has good test now! :)

[pnkfelix]

Note that if there's a way to do this without special-casing trait methods (which is what the rustc_privacy::PrivacyVisitor seems to be doing) that would also be a small patch that could be readily back-ported, I'm all ears.

But I figured this was the simplest fix for the short term that we could backport. Separately we might consider revising what fn visibility returns for trait methods, which I think of as being implicitly pub.

[petrochenkov]

Strictly speaking the fix is incorrect because stability annotations are based on reachability and not local pub annotations. However, with this patch it's highly unlikely to hit the ICE accidentally - you need something from one of std crates + stability-checked during type checking + pub + unreachable.
So, r=me, especially for beta.

[petrochenkov]

Alternatively, the ICE can just be removed, since it's no longer an error to encounter unmarked API 😄
Originally it was useful to catch bugs in the stability system which was hastily written just before 1.0, now it's not so direly needed.

[pnkfelix]

(I lean slightly towards landing this over removing the ICE, in terms of what seems safest to push into the beta. But I don't have a real strong feeling about it. If other members of T-compiler think removing the ICE is the way to go, then we can try that.)

[pnkfelix]

@petrochenkov also, just to clarify: Your point about this fix being technically incorrect is because it is imposing too strong a constraint on the code, right?

I ask because I'm having a little trouble envisaging the scenario where something would have stability attributes and not be locally declared pub, i.e. the reasoning I gave in this PR's description. As @eddyb pointed out to me when I started working on this, even items exposed via pub use have to themselves be declared pub, right?

[nikomatsakis]

I'm fine with landing this PR for now, but I'm not really following closely.

[petrochenkov]

@pnkfelix

also, just to clarify: Your point about this fix being technically incorrect is because it is imposing too strong a constraint on the code, right?

On the contrary, the constraints are not strong enough.
Something like

fn main() {
let a = std::sys::imp::process::process_common::StdioPipes { ..panic!() };
}

still should give and ICE with this patch because struct StdioPipes is pub, but unreachable and doesn't have a stability attribute.

[arielb1]

@petrochenkov

Sure enough, ignoring the absence of stability markers, at least for items whose resolution was an error, looks like a good idea.

[pnkfelix]

@petrochenkov ah thank you for the example input.

[nikomatsakis]

@pnkfelix do you then plan to revise the PR?

[alexcrichton]

@bors: p=1

(for when this is approved, we'll want to backport)

[pnkfelix]

@bors r=petrochenkov

[nikomatsakis]

Discussed in @rust-lang/compiler meeting. Consensus was to land this PR for the beta, since it seems less risky, but follow-up with @petrochenkov's example afterwards (probably removing the ICE). @petrochenkov, maybe you can file an issue with your example?

@bors r+

[bors]

📌 Commit ab8e925 has been approved by petrochenkov

[bors]

📌 Commit ab8e925 has been approved by nikomatsakis

[pnkfelix]

(the answer to @nikomatsakis 's Q above is that I did and do not plan to revise this particular PR. However I will open an issue to make sure that we address the fact that there remains an ICE, just a much rarer one, even with this PR applied, as noted by @petrochenkov )

[bors]

⌛ Testing commit ab8e925 with merge 42bed72...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 42bed72 to master...

[alexcrichton]

@pnkfelix this applies cleanly to beta but results in a build failure, could you take a look at backporting this to the beta branch?