This commit changes the default of rustc to use 32 codegen units when compiling
in debug mode, typically an opt-level=0 compilation. Since their inception
codegen units have matured quite a bit, gaining features such as:
* Parallel translation and codegen enabling codegen units to get worked on even
more quickly.
* Deterministic and reliable partitioning through the same infrastructure as
incremental compilation.
* Global rate limiting through the `jobserver` crate to avoid overloading the
system.
The largest benefit of codegen units has forever been faster compilation through
parallel processing of modules on the LLVM side of things, using all the cores
available on build machines that typically have many available. Some downsides
have been fixed through the features above, but the major downside remaining is
that using codegen units reduces opportunities for inlining and optimization.
This, however, doesn't matter much during debug builds!
In this commit the default number of codegen units for debug builds has been
raised from 1 to 32. This should enable most `cargo build` compiles that are
bottlenecked on translation and/or code generation to immediately see speedups
through parallelization on available cores.
Work is being done to *always* enable multiple codegen units (and therefore
parallel codegen) but it requires #44841 at least to be landed and stabilized,
but stay tuned if you're interested in that aspect!
Add suggestions for misspelled method names
Use the syntax::util::lev_distance module to provide suggestions when a
named method cannot be found.
Part of #30197
Require rlibs for dependent crates when linking static executables
This handles the case for `CrateTypeExecutable` and `+crt_static`. I reworked the match block to avoid duplicating the `attempt_static` and error checking code again (this case would have been a copy of the `CrateTypeCdylib`/`CrateTypeStaticlib` case).
On `linux-musl` targets where `std` was built with `crt_static = false` in `config.toml`, this change brings the test suite from entirely failing to mostly passing.
This change should not affect behavior for other crate types, or for targets which do not respect `+crt_static`.
Allow writing metadata without llvm
# Todo:
* [x] Rebase
* [x] Fix eventual errors
* [x] <strike>Find some crate to write elf files</strike> (will do it later)
Cc #43842
encode region::Scope using fewer bytes
Now that region::Scope is no longer interned, its size is more important. This PR encodes region::Scope in 8 bytes instead of 12, which should speed up region inference somewhat (perf testing needed) and should improve the margins on #36799 by 64MB (that's not a lot, I did this PR mostly to speed up region inference).
This is a perf-sensitive PR. Please don't roll me up.
r? @eddyb
This is based on #44743 so I could get more accurate measurements on #36799.
* Adjust bootstrap to provide useful output on failure
* Add missing package dependencies in the build environment
* Fix permission bits on prebuilt toolchain files
Move effect-checking to MIR
This allows emitting lints from MIR and moves the effect-checking pass to work on it.
I'll make `repr(packed)` misuse unsafe in a separate PR.
r? @eddyb
put empty generic lists behind a pointer
This reduces the size of hir::Expr from 128 to 88 bytes (!) and shaves
200MB out of #36799.
This is a performance-sensitive PR so please don't roll it up.
r? @eddyb
The convention for suggesting close matches is to provide at most one match (the
closest one). Change the suggestions for misspelt method names to obey that.
typeck::check::coercion - roll back failed unsizing type vars
This wraps unsizing coercions within an additional level of
`commit_if_ok`, which rolls back type variables if the unsizing coercion
fails. This prevents a large amount of type-variables from accumulating
while type-checking a large function, e.g. shaving 2GB off one of the
4GB peaks in #36799.
This is a performance-sensitive PR so please don't roll it up.
r? @eddyb
cc @nikomatsakis
Now that region::Scope is no longer interned, its size is more
important. This PR encodes region::Scope in 8 bytes instead of 12, which
should speed up region inference somewhat (perf testing needed) and
should improve the margins on #36799 by 64MB (that's not a lot, I did
this PR mostly to speed up region inference).
add comparison operators to must-use lint (under `fn_must_use` feature)
Although RFC 1940 is about annotating functions with `#[must_use]`, a
key part of the motivation was linting unused equality operators.
(See
https://github.com/rust-lang/rfcs/pull/1812#issuecomment-265695898—it
seems to have not been clear to discussants at the time that marking the
comparison methods as `must_use` would not give us the lints on
comparison operators, at least in (what the present author understood
as) the most straightforward implementation, as landed in #43728
(3645b062).)
To rectify the situation, we here lint unused comparison operators as
part of the unused-must-use lint (feature gated by the `fn_must_use`
feature flag, which now arguably becomes a slight (tolerable in the
opinion of the present author) misnomer).
This is in the matter of #43302.
cc @crumblingstatue
This wraps unsizing coercions within an additional level of
`commit_if_ok`, which rolls back type variables if the unsizing coercion
fails. This prevents a large amount of type-variables from accumulating
while type-checking a large function, e.g. shaving 2GB off one of the
4GB peaks in #36799.
Improve diagnostics when attempting to match tuple enum variant with struct pattern
Adds an extra note as below to explain that a tuple pattern was probably intended.
```
error[E0026]: variant `X::Y` does not have a field named `data`
--> src/main.rs:18:16
|
18 | X::Y { data } => println!("The data is {}", data)
| ^^^^ variant `X::Y` does not have field `data`
error[E0027]: pattern does not mention field `0`
--> src/main.rs:18:9
|
18 | X::Y { data } => println!("The data is {}", data)
| ^^^^^^^^^^^^^ missing field `0`
|
= note: trying to match a tuple variant with a struct variant pattern
```
Fixes#41314.
incr.comp.: Add new DepGraph implementation.
This commits does a few things:
1. It adds the new dep-graph implementation -- *in addition* to the old one. This way we can start testing the new implementation without switching all tests at once.
2. It persists the new dep-graph (which includes query result fingerprints) to the incr. comp. caching directory and also loads this data.
3. It removes support for loading fingerprints of metadata imported from other crates (except for when running autotests). This is not needed anymore with red/green. It could provide a performance advantage but that's yet to be determined. For now, as red/green is not fully implemented yet, the cross-crate incremental tests are disabled.
Note, this PR is based on top of soon-to-be-merged #44696 and only the last 4 commits are new:
```
- incr.comp.: Initial implemenation of append-only dep-graph. (c90147c)
- incr.comp.: Do some various cleanup. (8ce20c5)
- incr.comp.: Serialize and deserialize new DepGraph. (0e13c1a)
- incr.comp.: Remove support for loading metadata fingerprints. (270a134)
EDIT 2:
- incr.comp.: Make #[rustc_dirty/clean] test for fingerprint equality ... (d8f7ff9)
```
(EDIT: GH displays the commits in the wrong order for some reason)
Also note that this PR is expected to certainly result in performance regressions in the incr. comp. test cases, since we are adding quite a few things (a whole additional dep-graph, for example) without removing anything. End-to-end performance measurements will only make sense again after red/green is enabled and all the legacy tracking has been turned off.
EDIT 2: Pushed another commit that makes the `#[rustc_dirty]`/`#[rustc_clean]` based autotests compared query result fingerprints instead of testing `DepNode` existence.
