Restore public visibility on some parsing functions for rustfmt

[calebcartwright]

In #74826 the visibility of several parsing functions was reduced. However, rustfmt is an external consumer of some of these functions as well and needs the visibility to be public, similar to other elements in rustc_parse such as parse_ident

rust/src/librustc_parse/parser/mod.rs

Lines 433 to 436 in db534b3

	// Public for rustfmt usage.
	pub fn parse_ident(&mut self) -> PResult<'a, Ident> {
	self.parse_ident_common(true)
	}

[rust-highfive]

r? @nikomatsakis

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

[matklad]

@bors r+ rollup

@calebcartwright is there an easy way for me to check if rustfmt builds with current rustc_parse? Under wg-parslib, we will be changing parser's API a lot in the coming months, so I wonder if there are ways to alleviate the pain here...

[bors]

📌 Commit 883b1e7 has been approved by matklad

[calebcartwright]

@matklad

is there an easy way for me to check if rustfmt builds with current rustc_parse?

Unfortunately no, there really isn't. On rare occasions there's brief windows when it's possible to swap some of the dep references from the rustc auto publish crates to path based in-tree and vice versa, but that requires so many things to line up perfectly that it's not a really a viable approach.

It's the nature of the beast with the submod/auto-publish process, and we'd probably need to move to the subtree approach like clippy as @Manishearth has suggested to check/ensure that rustfmt and latest rustc_parse (and other rustc mods) are compatible.

Under wg-parslib, we will be changing parser's API a lot in the coming months, so I wonder if there are ways to alleviate the pain here

Thanks for the heads up, that's good to know!

Feel free to cc me if there's any questions/concerns about a rustfmt impact and I'll be happy to take a look. rustfmt uses rustc_parse, rustc_ast, and rustc_span extensively, so changes to any of their public members have a decent chance of causing breakage in rustfmt.

With the current process I don't think we'll be able to avoid that pain as the parser APIs are changed, but the earlier we're aware of those changes the more easily and quickly we'll be able to incorporate them in rustfmt. The thing we really want to avoid is running into a ton of breaking rustc changes that have to be resolved before we can address a broken rustfmt toolstate.

[Mark-Simulacrum]

If it's just building (cargo check) it wouldn't be too hard to wire up rustfmt to get checked as part of x.py check, likely off by default since it's allowed to be broken.

[calebcartwright]

If it's just building (cargo check) it wouldn't be too hard to wire up rustfmt to get checked as part of x.py check, likely off by default since it's allowed to be broken.

LMK if I misunderstood, but my interpretation of the ask was if there was something that could help determine if changes to public parsing APIs would impact rustfmt because of rustfmt's consumption of those APIs. I guess such a check could be done by swapping out all of rustfmt's rustc-ap crate deps to the corresponding in-tree mods?

That could shed some light on the impact of changes, but worth noting such a check would be in a near constant state of failure. As a reference, it would've been failing consistently for the last five weeks due to the renaming of check_name to has_name on MetaItem in rustc_ast alone, along with whatever other breaking changes in the other rustc mods consumed by rustfmt occured since our last rustc-ap bump.

[Mark-Simulacrum]

Sure, yes. I think such a check would probably only be useful if we were quicker about fixing upstream rustfmt, but with the current "update RLS rustfmt racer" scheme that's, uh, probably impractical.

@matklad let me know if you think an almost-always-broken with preexisting things check would still be useful.