Remove some unnecessary indirection from AST/HIR structures

[petrochenkov]

I've measured the time/memory consumption before and after - the difference is lost in statistical noise, so it's mostly a code simplification.
Sizes of enums are not affected.

r? @nrc

I wonder if AST/HIR visitors could run faster if Ps are systematically removed (except for cases where they control enum sizes). Theoretically they should.
Remaining unnecessary Ps can't be easily removed because many folders accept P<X>s as arguments, but these folders can be converted to accept Xs instead without loss of efficiency.
When I have a mood for some mindless refactoring again, I'll probably try to convert the folders, remove remaining Ps and measure again.

[nrc]

The HIR changes seem like a no-brainer - r+. However, I'm wary about changing the AST and breaking a whole lot of code for no real gain - is there any motivation I'm missing or is this just tidying up? If the latter, I'd rather not change the AST.

cc @eddyb who knows about P

[eddyb]

I should note that some (all?) of these are an artifact of @t and how the ast_map used to work (keeping shared boxes) - now they can disappear.

[petrochenkov]

I'm not sure how much things it will break.
Code reading AST should not be affected (mostly) because P is Deref, quasiquoting should not be affected. Code generating traits, impls, enums directly may be affected.
@Manishearth, maybe you can estimate better?

I'm totally ready to revert the AST part, but I'd like to hear some more opinions, because cleanup is still an improvement, albeit modest.

[Manishearth]

I think a bunch of Visitors might break. No biggie.

Clippy would break, because we use P in some of our functions (which expect the corresponding fields to be P<T>), but it's simple enough to upgrade over.

Code using aster on nightly will probably break too (so, serde). Not sure how easy the upgrade is there.

I'd expect some speed improvements here, surprised there aren't any. But I'm overall okay with this breakage.

[bors]

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

[petrochenkov]

Rebased.

[nrc]

It seems to me that @Manishearth's list of bustage is enough to justify not landing the AST parts.

I'd like to land the HIR parts now but not the AST parts. I do think the AST changes are worthwhile though, and if there is a PR in the future which makes breaking changes to the AST, then perhaps this could be landed at the same time.

[petrochenkov]

if there is a PR in the future which makes breaking changes to the AST, then perhaps this could be landed at the same time.

There is such a PR! #29850 landed two days ago. (It is the reason why I had to rebase this PR as well)

[nrc]

Ah, its a shame we didn't land them together. I think they have to land together (or at least to hit the same nightly) to get the benefit.

[Manishearth]

Note that I'm mostly okay with clippy breaking on minor things like this if I know in advance, and can fix it up pretty much immediately.

The existence of syntex makes things hard for us, though, since tiny public API changes still break compat when aster/etc are in the picture. Not sure how to handle that.

[petrochenkov]

Updated with AST changes reverted.
AST changes still live in a separate branch https://github.com/petrochenkov/rust/tree/indi_ast in case someone wants to apply them when the appropriate time comes.

[nrc]

@bors: r+

[bors]

📌 Commit ca88e9c has been approved by nrc

[bors]

⌛️ Testing commit ca88e9c with merge acf4e0b...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, 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-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt