permit crate as a shorthand visibility identifier

[nikomatsakis]

As part of #44660, we plan to support crate as a visibility modifier equivalent to pub(crate). Given that pub(crate) exists, this should be relatively straight-forward.

Visibilities are stored in the AST type Visibility. We will want to extend the Crate variant to include one additional field, indicating whether the sugar crate or the expanded form pub(crate) was used. We can add an enum like

enum CrateSugar {
    /// User wrote `pub(crate)`
    PubCrate,

    /// User wrote `crate`
    JustCrate,
}

and add this field to the Crate variant, so that it looks like Crate(Span, CrateSugar). Actually, at the same time we can remove the Span field, which appears to be unused, so it would just become Crate(CrateSugar). Doing this simultaneously is sorta bad but will save you some editing, since all existing uses look like Crate(_), and 99% of them want to ignore the CrateSugar field anyway. =)

The one user that does NOT want to ignore CrateSugar is the pretty printer. We just want to change this line to something like:

 ast::Visibility::Crate(CrateSugar::PubCrate) => self.word_nbsp("pub(crate)"),
 ast::Visibility::Crate(CrateSugar::JustCrate) => self.word_nbsp("crate"),

Naturally, we also will want to alter the parser itself, in particular the parse_visibility function. Currently, if it doesn't see the word pub, it just returns. We need to extend this to look for crate and -- if it finds it -- to return the new visibility (with sugar JustCrate). We also need to modify the existing pub(crate) code to return PubCrate for the sugar.

(Note: Please limit discussion on this issue strictly to implementation concerns relative to this particular change. Policy discussion as to whether or not to make this change -- or whether to make other changes to the module system -- belong in #44660.)

[kennytm]

To implementors: Ensure tests related to :vis (#41022) are updated as well.

[zackmdavis]

I volunteer.

[nikomatsakis]

Seems like this is done!

[dtolnay]

Reopening as a tracking issue because feature(crate_visibility_modifier) still refers here.

error[E0658]: `crate` visibility modifier is experimental (see issue #45388)
 --> src/main.rs:1:1
  |
1 | crate struct S;
  | ^^^^^
  |
  = help: add #![feature(crate_visibility_modifier)] to the crate attributes to enable

[nikomatsakis]

cc @rust-lang/lang @petrochenkov -- I really want to stabilize the crate visibility modifier. However, there is one issue we ought to resolve first:

struct Foo(crate :: X)

This is presently interpreted as crate (::X), I believe, as opposed to (crate::X).

I am not sure that this is correct: I would think that, since :: paths are more-or-less deprecated now that we have the extern_prelude feature, the correct interpretation would be struct Foo( crate::X ) -- that is, a single private field of type crate::X.

(But if we stabilized crate as is, people could write that sort of code, and we'd be locked in.)

[petrochenkov]

@nikomatsakis
struct Foo(crate :: X) is already interpreted as struct Foo( (crate::X) ) actually, i.e. a single private field of type crate::X, it was interpreted like this from the start (#45771).

// `#![feature(crate_visibility_modifier)]` is not required
#![feature(crate_in_paths)] // <-- On the other hand, this is required

struct Z;

mod m {
    pub struct S(crate::Z);
    
    pub fn get_s() -> S { S(::Z) }
}

fn main() {
    m::get_s().0; // ERROR field `0` of struct `m::S` is private
}

[est31]

Could we get an FCP to stabilize then?

[joshtriplett]

I don't think we should stabilize this until we finalize the module changes. There's still some active discussion on one last point of those: whether to write crate::foo or ::foo. If we settle on the latter (which, personally, I'd prefer) then that would change the interpretation of the struct declarations above.

Let's wait and stabilize all of them together, as a unit, in the combination we settle on.

[est31]

@joshtriplett do you have any pointers to places where that discussion is happening?

[joshtriplett]

@est31 The last discussions I saw were on internals.rust-lang.org threads; I believe they're in a bit of a lull at the moment due to attention placed on the edition.

[Ixrec]

I haven't seen any discussion on leading crate vs leading :: since https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678 ended in March.

[joshtriplett]

@Ixrec Likewise.

[Centril]

This is a duplicate issue of #53120; so I'm closing this one.