Parse pub(restricted) visibilities on tuple struct fields

[jseyfried]

Parse pub(restricted) on tuple struct fields (cc #32409).

r? @nikomatsakis

[jseyfried]

cc @petrochenkov

[petrochenkov]

Ha, I expected to implement this myself today.

I'd like to see more tests for error messages for failed reinterpretation.
Also, ty nonterminals shouldn't be interpreted as visibilities even if they expand into (path), i.e. pub $t u8 or pub ($t) u8 where $t: ty shouldn't parse (this needs tests too).

[jseyfried]

@petrochenkov

I'd like to see more tests for error messages for failed reinterpretation.

Will do. Do you think there should be a different error message for failed reinterpretation?
Now, pub(non-path type) ... behaves exactly as it did before this PR.

Also, ty nonterminals shouldn't be interpreted as visibilities even if they expand into (path)

Good point, I hadn't considered that. Will do.

[petrochenkov]

Do you think there should be a different error message for failed reinterpretation?

It just needs to be reasonable, I think the current one is ok.

[bors]

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

[jseyfried]

cf #33188

[jseyfried]

@nikomatsakis we have this test case, but the macro id should be

#![feature(type_macros)]macro_rules! id {($t:ty) => { $t }}

instead of how it is defined now.

Is this the type of test you had in mind?

[jseyfried]

I can add more tests, but due to poor error recovery we need one test per parse error.

[jseyfried]

I rebased and addressed @petrochenkov's comments.

[nikomatsakis]

Do we have any tests covering this interpolated case? I expected to see one where we substitute in a $t:ty.

It is a bit of a shame that we have no $p:path fragment specificier, though I guess rust-lang/rfcs#1575 would address the use case.

[nikomatsakis]

@jseyfried

Is this the type of test you had in mind?

Yes, and maybe also having pub($t) in the expansion?

[jseyfried]

also having pub($t) in the expansion?

Good point, will do.

[nikomatsakis]

r=me w/ a few more tests

also, @jseyfried, you can I think use the revisions mechanism if you'd prefer to have multiple errors per file. You have to add

// revisions: a b c

then write code with #[cfg(a)] etc. You can then specify the expected error as

//[a] error-pattern:foo

or //[a]~ ERROR foo.

[nikomatsakis]

(Though maybe it doesn't work with that class of test yet)

[jseyfried]

use the revisions mechanism if you'd prefer to have multiple errors per file

Interesting, I'll give it a try.

[jseyfried]

The revisions mechanism won't work for parse errors since we always parse and expand unconfigured items (cf my comment in #25544).

[jseyfried]

@bors r=nikomatsakis

[bors]

📌 Commit 78a8127 has been approved by nikomatsakis

[bors]

⌛ Testing commit 78a8127 with merge 0f9ba99...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-32cross-opt, auto-linux-64-cargotest, auto-linux-64-cross-armhf, auto-linux-64-cross-armsf, auto-linux-64-cross-freebsd, auto-linux-64-cross-netbsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild