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

Implement pub(restricted) privacy (RFC 1422) #32875

Merged
merged 11 commits into from
Apr 17, 2016

Conversation

jseyfried
Copy link
Contributor

@jseyfried jseyfried commented Apr 11, 2016

This implements pub(restricted) privacy from rust-lang/rfcs#1422 (cc #32409) behind a feature gate.

pub(restricted) paths currently cannot use re-exported modules both for simplicity of implementation and for future compatibility with rust-lang/rfcs#1560 (cc #31783).

r? @nikomatsakis

@jseyfried
Copy link
Contributor Author

I didn't allow pub(restricted) for tuple struct fields, as suggested here.

Also, pub(restricted) imports cannot be used in non-lexical scopes (like private imports) so that pub(self) and the absence of a visibility modifier are equivalent (as suggested here). Once RFC 1560 is accepted and #32213 lands, all imports will be usable in non-lexical scopes (provided that they are visible enough, of course).

@jseyfried
Copy link
Contributor Author

cc @petrochenkov @pnkfelix

@jseyfried jseyfried force-pushed the 1422_implementation branch 2 times, most recently from 84e1cdb to ef05df9 Compare April 11, 2016 08:22
@@ -949,6 +928,9 @@ pub struct NameBinding<'a> {
modifiers: DefModifiers,
kind: NameBindingKind<'a>,
span: Option<Span>,
// Enum variants are always considered `PUBLIC`, this is needed for `use Enum::Variant`
// or `use Enum::*` to work on private enums.
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment is no longer true after d1ef356?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed, fixed.

@@ -619,6 +621,7 @@ pub fn walk_struct_def<'v, V: Visitor<'v>>(visitor: &mut V,

pub fn walk_struct_field<'v, V: Visitor<'v>>(visitor: &mut V,
struct_field: &'v StructField) {
visitor.visit_vis(&struct_field.vis);
walk_opt_ident(visitor, struct_field.span, struct_field.ident);
visitor.visit_ty(&struct_field.ty);
walk_list!(visitor, visit_attribute, &struct_field.attrs);
Copy link
Contributor

Choose a reason for hiding this comment

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

Foreign items seem to be missing.

Copy link
Contributor

Choose a reason for hiding this comment

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

And HIR visibilities in librustc\hir\intravisit.rs are not visited.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Foreign items seem to be missing.

Good catch, I'll add them.

And HIR visibilities in librustc\hir\intravisit.rs are not visited.

There's no need to visit visibilities in the HIR currently -- do you think I should add a visit_vis method in intravisit anyway?

Copy link
Contributor

Choose a reason for hiding this comment

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

do you think I should a visit_vis method in intravisit

Yes, default visitor functions just traverse the tree exhaustively, providing, well, correct defaults.
As an example, overridden visit_paths will not visit paths in visibilities if intravisit doesn't traverse visibilities by default.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Copy link
Contributor

Choose a reason for hiding this comment

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

I've just noticed, default folders (fold.rs) have the same problems as visitors.
AST folders don't fold all visibilities and HIR folders don't fold visibilities at all.

Copy link
Contributor Author

@jseyfried jseyfried Apr 14, 2016

Choose a reason for hiding this comment

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

Done.

@jseyfried
Copy link
Contributor Author

I rebased and addressed @petrochenkov's comments.

@bors
Copy link
Contributor

bors commented Apr 13, 2016

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

@@ -0,0 +1,31 @@
// Copyright 2016 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
Copy link
Contributor

Choose a reason for hiding this comment

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

Meta note: Let's make a subdirectory for these tests.

Perhaps src/test/compile-fail/privacy? If we want to further designate tests aimed at the pub(restricted) RFC, then perhaps src/test/compile-fail/privacy/restricted?

@nikomatsakis
Copy link
Contributor

This looks great. I suggest we move the privacy tests to a subdirectory. I want to start giving more structure to our compile-fail directory on new PRs. :) I'd also like to start maintaining a list that aims to show what is being tested (and, ideally, where). To that end, I drew up a list of stuff that I think we ought to test from this RFC and went through and checked off what you were already testing. The good news is that you got almost all of it! I'm going to write up my matrix here, maybe you can add tests for the remaining few items. In some cases, the tests are probably a bit redundant: I was just trying to think -- without reference to the impl -- of the various scenarios that might arise and try to be somewhat exhaustive about it.

So, here is my matrix. I've put an X for things that I thought you were testing, a - for cases that don't really apply, and left blank things that seem untested. I also added in an O in a few spots for the things I'd really like to see tests for. The rest I think you can add tests for if you think it makes sense.

pub(crate)                                              | X | X |
pub(super)                                              | X | X |
pub(other::path)                                        | X |   |
pub(bad::path)                                          | X | - |
pub(not::ancestor)                                      | X | - |
method calls                                            | X | X |
field access                                            | X | X |
struct literal where fields are private                 | X |   |
field lookup ignores fields with pub(foo)               | O | O |
method lookup ignores fields with pub(foo)              | O | O |
associated item notation (UFCS)                         |   |   |
  trait method (in scope, from parent)                  |   |   |
  inherent method (in scope, from parent)               |   |   |
  where trait is out of scope                           | O | O |
  where method is out of scope (inherent methods only)  | O | O |
reference of item in use statement                      | X | X |
reference of item in expression                         | X | X |
reference of item in type definition                    |   |   |
reference of trait in an impl                           |   |   |
reference of self-type in a trait impl                  |   |   |
reference of self-type in an inherent impl              |   |   |
feature-gate required                                   | X | - |
private type in public API:                             |   |   |
  fn arg                                                | X |   |
  other cases?                                          |   |   |

Eventually I'd like to have a system for tagging tests with what they test so we can easily construct matrices like this automatically to get some idea of test coverage. But we're not there yet.

r=me with suitable tests added.

@jseyfried
Copy link
Contributor Author

jseyfried commented Apr 14, 2016

@nikomatsakis
What are the columns? I'm guessing something like [ error emitted | no error emitted ].
Other than that, sounds good.

@nikomatsakis
Copy link
Contributor

@jseyfried oh, I forgot to label those :) it was "intra-crate" and "cross-crate"

@nikomatsakis
Copy link
Contributor

@jseyfried if you want me to review add'l tests, let me know, but if you feel like you've satisfied all the interesting points in that matrix, then r=me

@jseyfried
Copy link
Contributor Author

jseyfried commented Apr 16, 2016

Ok, makes sense. I'll add some more tests and r=you

@petrochenkov
Copy link
Contributor

A note: visibilities do not expect type parameters in paths, but use parse_path for parsing, so paths with type parameters can be supplied to them with macros $p: path => pub($p), so visibilities need to be sanity-checked after expansion. I'll fix this as a part of #32875 (comment).

the feature `pub_restricted` is enabled.
@jseyfried
Copy link
Contributor Author

@petrochenkov interesting, sounds good.

@jseyfried
Copy link
Contributor Author

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Apr 16, 2016

📌 Commit e14504a has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Apr 16, 2016

⌛ Testing commit e14504a with merge ae33aa7...

bors added a commit that referenced this pull request Apr 16, 2016
Implement `pub(restricted)` privacy (RFC 1422)

This implements `pub(restricted)` privacy from RFC 1422 (cc #32409) behind a feature gate.

`pub(restricted)` paths currently cannot use re-exported modules both for simplicity of implementation and for future compatibility with RFC 1560 (cf #31783).

r? @nikomatsakis
@bors bors merged commit e14504a into rust-lang:master Apr 17, 2016
Manishearth added a commit to Manishearth/rust that referenced this pull request Apr 17, 2016
resolve: Refactor away `DefModifiers`

This refactors away `DefModifiers`, which is unneeded now that rust-lang#32875 has landed.
r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants