Load proc macro metadata in the correct order.

[Aaron1011]

Serialized proc macro metadata is assumed to have a one-to-one
correspondence with the entries in static array generated by proc_macro_harness.
However, we were previously serializing proc macro metadata in a
different order than proc macros were laied out in the static array.
This lead to us associating the wrong data with a proc macro when
generating documentation, causing Rustdoc to generate incorrect docs for
proc macros.

This commit keeps track of the order in which we insert proc macros into
the generated static array. We use this same order when serializing proc
macro metadata, ensuring that we can later associate the metadata for a
proc macro with its entry in the static array.

Fixes #64251

[rust-highfive]

r? @alexcrichton

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

[Centril]

cc @petrochenkov @eddyb

[alexcrichton]

I'm not super familiar with this but from my perspective it seems like a sort of odd field to add to the AST, it seems like a better solution might be to ensure that the raw proc macro harnesses are in the same order as the AST, or ensuring that they're encoded in the same order that the harnesses show up (which appears to basically be sorted by type)

[Aaron1011]

it seems like a better solution might be to ensure that the raw proc macro harnesses are in the same order as the AST

How is this different from your second suggestion?

or ensuring that they're encoded in the same order that the harnesses show up (which appears to basically be sorted by type)

I considered that - however, it seems very fragile to me. The harness code runs very early on, and depends on the AST order. When we (currently) serialize proc macro data, we rely on the HIR order, which AFAIK is not guaranteed to be equivalent to the AST order in any way.

We could sort the proc macros before generating harnesses, but this would require us to ensure that the sorting stays in sync between the harness code and the metadata serialization. It seems much simpler to just record the actual order used by the harness code, and not worry about what that order ends up being.

[petrochenkov]

we rely on the HIR order, which AFAIK is not guaranteed to be equivalent to the AST order in any way.

HIR visiting order needs to follow AST visiting order when it matters (e.g. any parameter/argument order, or statement order) and don't have many reasons to deviate from it even when it technically could.
Proc macros is just one more place where the order matters.

I'd change the harness to visit macros in the AST visiting order, without grouping into derives/attributes/etc, that's a pretty easy order to keep in sync.

[Aaron1011]

@petrochenkov @alexcrichton : I've modified the harness code to generate macro definitions in AST order.

[alexcrichton]

@bors: r+

[bors]

📌 Commit 3daa8bd has been approved by alexcrichton