This increases regionck performance greatly - type-checking on
librustc decreased from 9.1s to 8.1s. Because of Amdahl's law,
total performance is improved only by about 1.5% (LLVM wizards,
this is your opportunity to shine!).
before:
576.91user 4.26system 7:42.36elapsed 125%CPU (0avgtext+0avgdata 1142192maxresident)k
after:
566.50user 4.84system 7:36.84elapsed 125%CPU (0avgtext+0avgdata 1124304maxresident)k
I am somewhat worried really need to find out why we have this Red Queen's
Race going on here. Originally I suspected it may be a problem from RFC1214's
warnings, but it seems to be an effect from other changes.
However, the increase seems to be mostly in LLVM's time, so I guess
it's the LLVM wizards' problem.
Since enums are namespaced now, should we also remove the `Fk` prefixes from `FnKind` and remove the reexport? (The reexport must be removed because otherwise it clashes with glob imports containing `ItemFn`). IMO writing `FnKind::Method` is much clearer than `FkMethod`.
also, use the right caching logic for type_moves_by_default (this was
broken by @jroesch).
```
before:
593.10user 5.21system 7:51.41elapsed 126%CPU (0avgtext+0avgdata 1150016maxresident)k
after:
567.03user 4.00system 7:28.23elapsed 127%CPU (0avgtext+0avgdata 1133112maxresident)k
```
A nice 4.5% improvement. For reference, on the last run LLVM takes 429.267s, which is 75% - hopefully this can be reduced.
I think the regression since #27751 is because of the wf patch - need to investigate it through.
r? @nikomatsakis
Just a little code cleanup I was doing as part of another refactoring (which may turn out not to be needed). The main thrust of this is to cleanup the interface to `tydecode.rs` to be less ridiculously repetitive. I also purged the generic "def-id conversion" parameter in favor of a trait object, just to reduce code duplication a bit and make the signatures a bit less messy. I measured the bootstrapping time to build stage2 with these changes, it was identical. (But it'd be easy enough to restore the unboxed closure if we wanted it.)
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
[rfc]: https://github.com/rust-lang/rfcs/pull/1183
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
Closes#27389
