Avoid many CrateConfig clones.

[nnethercote]

This commit changes ExtCtx::cfg() so it returns a CrateConfig
reference instead of a clone. As a result, it also changes all of the
cfg() callsites to explicitly clone... except one, because the commit
also changes macro_parser::parse() to take &CrateConfig. This is
good, because that function can be hot, and CrateConfig is expensive
to clone.

This change almost halves the number of heap allocations done by rustc
for html5ever in rustc-benchmarks suite, which makes compilation 1.20x
faster.

r? @nrc

[eddyb]

If we can't use references in some cases but the data is always immutable, why not wrap it in Rc?

[nnethercote]

I tried making it a &'a CrateConfig throughout, similar to sess, but there were some tricky bits that I couldn't work get to work. And this change is very simple and gets 99% of the benefit.

[eddyb]

I mean, either Rc<CrateConfig> or using Rc inside CrateConfig should be at most as invasive, if not less, and handle all the cases so no data is ever cloned. This may improve a lot of crates' expansion.

[nnethercote]

This may improve a lot of crates' expansion.

I don't understand what you mean by this. Can you elaborate? Thanks.

[eddyb]

I mean that there's still many clones and some of them may contribute to expansion times in other crates.
In principle, if fixing all cases is possible, it should be done, instead of specializing for one profile.

[nnethercote]

In principle, if fixing all cases is possible, it should be done, instead of specializing for one profile.

Premature optimization, don't let perfect be the enemy of good, etc, etc. Let's see what @nrc thinks.

[eddyb]

Hey I thought the motto of Rust was "Don't let 'good enough' be the enemy of 'perfect'" 😆

[nnethercote]

Hey I thought the motto of Rust was "Don't let 'good enough' be the enemy of 'perfect'" 😆

I know you are at least partly joking, but I will respond seriously: an uncompromising attitude like that makes sense for aspects of Rust's design as a language -- e.g. no compromise on memory safety -- but I don't think the same attitude is necessarily relevant or helpful when it comes to the compiler implementation.

[nrc]

@bors: r+

It would be interesting to try @eddyb's Rc approach, but this PR makes things strictly better than they are at the moment, so no reason not to land it.

[bors]

📌 Commit 029dcee has been approved by nrc

[eddyb]

@nrc This PR adds clone calls all over the place, using Rc would be simpler, that's why I mentioned it.

[nnethercote]

It would be interesting to try @eddyb's Rc approach

@jseyfried ended up removing all the CrateConfig clones a different (and better) way in #37431.