Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged

Conversation

pnkfelix
Copy link
Member

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
Copy link
Collaborator

r? @arielb1

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

@pnkfelix
Copy link
Member Author

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 pnkfelix added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Dec 29, 2016
@pnkfelix
Copy link
Member Author

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

@nikomatsakis nikomatsakis added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Dec 30, 2016
@nikomatsakis
Copy link
Contributor

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

@@ -432,6 +432,18 @@ struct Checker<'a, 'tcx: 'a> {
}

impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> {
fn skip_stability_check_due_to_privacy(self, def_id: DefId) -> bool {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

arielb1 commented Dec 30, 2016

test?

@pnkfelix pnkfelix force-pushed the dont-check-stability-on-private-items branch from 751cd72 to ab8e925 Compare January 3, 2017 14:58
@pnkfelix
Copy link
Member Author

pnkfelix commented Jan 3, 2017

@arielb1 okay has good test now! :)

@pnkfelix
Copy link
Member Author

pnkfelix commented Jan 3, 2017

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member Author

pnkfelix commented Jan 3, 2017

(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 pnkfelix added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 3, 2017
@pnkfelix
Copy link
Member Author

pnkfelix commented Jan 3, 2017

@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
Copy link
Contributor

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

@petrochenkov
Copy link
Contributor

@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
Copy link
Contributor

arielb1 commented Jan 3, 2017

@petrochenkov

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

@pnkfelix
Copy link
Member Author

pnkfelix commented Jan 4, 2017

@petrochenkov ah thank you for the example input.

@nikomatsakis
Copy link
Contributor

@pnkfelix do you then plan to revise the PR?

@alexcrichton
Copy link
Member

@bors: p=1

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

@pnkfelix
Copy link
Member Author

pnkfelix commented Jan 5, 2017

@bors r=petrochenkov

@nikomatsakis
Copy link
Contributor

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
Copy link
Contributor

bors commented Jan 5, 2017

📌 Commit ab8e925 has been approved by petrochenkov

@bors
Copy link
Contributor

bors commented Jan 5, 2017

📌 Commit ab8e925 has been approved by nikomatsakis

@pnkfelix
Copy link
Member Author

pnkfelix commented Jan 5, 2017

(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
Copy link
Contributor

bors commented Jan 5, 2017

⌛ Testing commit ab8e925 with merge 42bed72...

bors added a commit that referenced this pull request Jan 5, 2017
…, r=nikomatsakis

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

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.
@bors
Copy link
Contributor

bors commented Jan 6, 2017

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

@bors bors merged commit ab8e925 into rust-lang:master Jan 6, 2017
@alexcrichton
Copy link
Member

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

@nikomatsakis nikomatsakis mentioned this pull request Jan 6, 2017
17 tasks
@alexcrichton alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jan 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants