This requires restructuring things a little so that there is only one
callsite, ensuring that inlinining doesn't cause unnecessary code bloat.
This reduces instruction counts for the `unicode_normalization`
benchmark by up to 4%.
Multiple people have asked for them, in
https://github.com/rust-lang/rust/issues/49137.
Given that the unsigned ones already exist,
they are very easy to add and not an additional maintenance burden.
Turns out that the equality check for regions is rather expensive, and
the current early exit check works in such a way, that the comparison is
even done twice. As we only really care about the case of equal scopes,
we can perform a faster, more specialized check and move it up one
level, so we can eventually skip the additional full comparison as well.
Prepare beta 1.33.0
This PR includes the usual changes for a new beta, and suppresses a few lints on libcore: those lints are false positives caused by an internal attribute (`rustc_layout_scalar_valid_range_start`) and only happen on stage0.
r? @Mark-Simulacrum
It's a level of indirection that hurts far more than it helps. The code
is simpler without it. (This commit cuts more than 120 lines of code.)
In particular, this commit removes some unnecessary `Span`s within
`DeclKind` that were always identical to those in the enclosing `Stmt`,
and some unnecessary allocations via `P`.
Always calculate glob map but only for glob uses
Previously calculating glob map was *opt-in*, however it did record node id -> ident use for every use directive. This aims to see if we can unconditionally calculate the glob map and not regress performance.
Main motivation is to get rid of some of the moving pieces and simplify the compilation interface - this would allow us to entirely remove `CrateAnalysis`. Later, we could easily expose a relevant query, similar to the likes of `maybe_unused_trait_import` (so using precomputed data from the resolver, but which could be rewritten to be on-demand).
r? @nikomatsakis
Local perf run showed mostly noise (except `ctfe-stress-*`) but I'd appreciate if we could do a perf run run here and double-check that this won't regress performance.
