Move process_configure_mod to rustc_parse

[Mark-Simulacrum]

This removes the hack in favor of perhaps a less principled, but less painful, approach.

This also supports my work to decouple Session from librustc, as ParseSess currently has Attribute as "part" of it but after this PR will no longer do so.

[Centril]

So this is basically undoing the point of 5011ec7.

This also supports my work to decouple Session from librustc, as ParseSess currently has Attribute as "part" of it but after this PR will no longer do so.

Can you elaborate on why Attribute presents a problem for the decoupling? Do you intend to decouple Session from libsyntax as well? That seems difficult for other reasons (e.g. features: Once<Features> also induces a dependency on libsyntax).

[Mark-Simulacrum]

Attribute is a pretty complicated type (pulls in TokenStream, Path, MetaItem, etc.); the other obstacles to moving Session before libsyntax I've already eliminated on that branch.

Generally speaking I think 5011ec7 is unrelated? Maybe you pointed at the wrong commit and meant be023eb?

But regardless, I acknowledge that, but it seems like the placement into syntax_expand is just a matter of 'cfg should in theory be implemented via expansion, not tied into the parser.' I don't disagree with that goal, but I don't think we should pay the price in complexity -- threading through an fn-ptr/trait through multiple modules. AFAICT, that price would go away with the more correct design (i.e., resolving #64197), so it's not really preparing us for anything. I guess it pretty loudly shouts "oh no here's something that should be fixed" -- but I don't think we should try to actively make our lives harder just because there's not great splitting of responsibilities in the current design if it can be avoided.

[Centril]

[...] the other obstacles to moving Session before libsyntax I've already eliminated on that branch.

I see. I can understand this PR better in light of making Session independent of libsyntax. Since you're talking about "that branch", do you happen to have it available so I can understand the bigger picture?

Generally speaking I think 5011ec7 is unrelated? Maybe you pointed at the wrong commit and meant be023eb?

Yeah that's right.

but I don't think we should try to actively make our lives harder just because there's not great splitting of responsibilities in the current design if it can be avoided.

That's a fair enough point; some of the benefits from be023eb are still there this seems like a substantially smaller revert.

r=me once CI agrees, unless @petrochenkov has other thoughts.

[Mark-Simulacrum]

master...Mark-Simulacrum:sess-decouple is the other branch (but we should not derail discussion here based on it); I think that if this PR doesn't stand alone successfully then I can include the commits onto that branch and we can see if the whole stands alone :)

[Mark-Simulacrum]

I'm going to leave this to @petrochenkov's approval.

[petrochenkov]

Well, at least it isn't moved back to libsyntax.
@bors r+

[bors]

📌 Commit 70805e6 has been approved by petrochenkov

[bors]

⌛ Testing commit 70805e6 with merge eaac45a...

[bors]

☀️ Test successful - checks-azure
Approved by: petrochenkov
Pushing eaac45a to master...