Refactor global paths

[jseyfried]

This PR removes the field global: bool from ast::Path and hir::Path, instead representing a global path ::foo::bar as {{root}}::foo::bar, where {{root}} is a virtual keyword keywords::CrateRoot.

Also, fixes#38016.

r? @nrc

[jseyfried]

This is groundwork for hygiene 2.0, specifically hygienic global paths between crates.

Since we will need the CrateRoot ident's ctxt to hygienically resolve semantically global paths, use foo; must parse into use {{root}}::foo; (use foo; and use ::foo; now parse into the same AST).

Alternatively, we could instead support hygienic global paths between crates by adding a field ctxt: SyntaxContext to today's Path that we would mark in the Marker fold.

[jseyfried]

cc @eddyb@petrochenkov

[petrochenkov]

I wanted to review this PR, but forgot, sorry.

Is the intent to eliminate $crate and just use ::path in macros (2.0)?
I looked through the diff and this refactoring doesn't seem to be especially useful for that goal, neither it removes significant amount of code.
Does this affect results of -Z hir-stats noticeably?
Maybe Option<Marker> could be used instead (None for lexical paths and Some(..) for global)?

[jseyfried]

@petrochenkov

Is the intent to eliminate $crate and just use ::path in macros (2.0)?

Yeah, global paths should be hygienic by default for macros 2.0, so we won't need $crate.

this refactoring doesn't seem to be especially useful for that goal

This refactoring will allow us to use nearly the same logic to resolve {{root}} hygienically as we currently use to resolve $crate, which I think is nice aesthetically. That being said, it would also be simple to resolve hygienically if Path instead had a field SyntaxContext or Option<SyntaxContext>.

Does this affect results of -Z hir-stats noticeably?

I haven't measured it, but I don't expect this to have a significant effect on hir stats. I could instead leave hir paths unchanged and just refactor ast paths -- IIRC refactoring hir paths only caused fallout in the lowerer and pretty printer.

ast::Path is part of the largest variant in a couple of ast enums though, and this refactoring did slightly improve memory usage and performance during parsing and expansion. The perf improvement should be more pronounced after the "Optimize ast::PathSegment" commit from #38171 lands -- I'll measure more thoroughly then.

[bors]

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

[nrc]

r=me with the minor refactoring

[nrc]

I think I would like an is_global method on paths, rather than having checks like this (path.segments[0].identifier.name == keywords::CrateRoot.name()) scattered around the code. It will also make it easier for tools using the AST.

[jseyfried]

Good point -- will do.

[nrc]

Perhaps also for segments

[bors]

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

[jseyfried]

@nrc I added a commit to fix #38016 by pretty-printing $crate::path as ::path (as discussed on IRC).

[nrc]

r = me, but you have test failures now

[jseyfried]

@bors r=nrc

[bors]

📌 Commit 8a1acb2 has been approved by nrc

[bors]

⌛ Testing commit 8a1acb2 with merge b86cb75...

[bors]

💔 Test failed - auto-mac-32-opt

[jseyfried]

@bors retry

[bors]

⌛ Testing commit 8a1acb2 with merge 82611a0...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, 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-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild
Approved by: nrc
Pushing 82611a0 to master...