This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.
Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.
Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.
A few points of note here are:
* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
entires for `cargo test` to naturally pick up. This mean that `cargo test -p
core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
rust-lang/cargo#860, but we can likely alleviate this restriction once
workspaces are implemented.
cc #31590
typeck: limit number of candidates shown for a single error
No idea if 10/11 is a good limit. Are there any other such limits in rustc currently?
Fixes: #25356
const_fn: Check the terminating expression of a block for blocks in a const initializer
In a const or static initializer, the `CheckBlock` check ensures that blocks in the initializer expression are only in tail positions or in items. In this case, it didn't check the terminating expression of a block, which resulted in an ICE later in the compiler pipeline if the trailing expression was itself a block. This change fixes the ICE and ensures that the proper error is emitted. This fixes the ICE in #32829 .
Currently, all switches in MIR are exhausitive, meaning that we can have
a lot of arms that all go to the same basic block, the extreme case
being an if-let expression which results in just 2 possible cases, be
might end up with hundreds of arms for large enums.
To improve this situation and give LLVM less code to chew on, we can
detect whether there's a pre-dominant target basic block in a switch
and then promote this to be the default target, not translating the
corresponding arms at all.
In combination with #33544 this makes unoptimized MIR trans of
nickel.rs as fast as using old trans and greatly improves the times for
optimized builds, which are only 30-40% slower instead of ~300%.
cc #33111
trivial tweaks to documentation (book)
These are small things I found while reading through The Book. The `<hash>` and `panic!` lines are simply to improve readability, while I believe the proceeding/following distinction is a bug (but might be a English dialect distinction?).
I've read `rust/CONTRIBUTING`, i'm not sure if there is anything I need to do other than submit this PR.
r? @steveklabnik
Add rustc_on_unimplemented for Index implementation on slice
Reopening of #31071.
It also extends the possibility of `#[rustc_on_unimplemented]` by providing a small type filter in order to find the ones which corresponds the most.
r? @pnkfelix
mk: Fix dependencies of unwind crate on musl
The libunwind.a library was accidentally only being included for the standard
library, not the new unwind crate which implements an unwinder.
Currently, to prepare for MIR trans, we break _all_ critical edges,
although we only actually need to do this for edges originating from a
call that gets translated to an invoke instruction in LLVM.
This has the unfortunate effect of undoing a bunch of the things that
SimplifyCfg has done. A particularly bad case arises when you have a
C-like enum with N variants and a derived PartialEq implementation.
In that case, the match on the (&lhs, &rhs) tuple gets translated into
nested matches with N arms each and a basic block each, resulting in N²
basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks, but
breaking the critical edges means that we go back to N².
In nickel.rs, there is such an enum with roughly N=800. So we get about
640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to
reduce that to the final "disr_a == disr_b".
So before this patch, we had 2.5M lines of IR with 640K basic blocks,
which took about about 3.6s in LLVM to get optimized and translated.
After this patch, we get about 650K lines with about 1.6K basic blocks
and spent a little less than 0.2s in LLVM.
cc #33111
fix DFS for region error reporting
This was causing terrible error reports, because the algorithm was incorrectly identifying the constraints.
r? @eddyb
middle: reset loop labels while visiting closure
This should fix#31754 and follow-up #25343. Before the latter, the closure was visited twice in the context of the enclosing fn, which made even a single closure with a loop label emit a warning.
With this change, the closure is still visited within the context of the main fn (which is intended, since it is not a separate item) but resets the found loop labels while being visited.
Fixes: #31754
Note: I amended the test file from #25343, but I don't know if the original or amended test are effective, since as far as I could see, compiletest's run-pass tests do not check for zero warnings emitted?
/cc @Manishearth
