Once upon a time, along with START_BLOCK and END_BLOCK in the castle of important blocks also lived
a RESUME_BLOCK (or was it UNWIND_BLOCK? Either works, I don’t remember anymore). This trinity of
important blocks were required to always exist from the birth to death of the MIR-land they
belonged to.
Some time later, it was discovered that RESUME_BLOCK was just a lazy goon enjoying comfortable life
in the light of fame of the other two. Needless to say, once found out, the RESUME_BLOCK was
quickly slain and disposed of.
Now, the all-seeing eye of ours discovers that END_BLOCK is actually the more evil and better
disguised twin of the slain RESUME_BLOCK. Thus END_BLOCK gets slain and quickly disposed
of. Glory to the START_BLOCK, one and only lord of the important blocks’ castle!
---
Basically, all this does, is removing restriction for END_BLOCK to exist past the first invocation
of RemoveDeadBlocks pass. This way for functions whose CFG does not reach the `END_BLOCK` end up
not containing the block.
As far as the implementation goes, I’m not entirely satisfied with the `BasicBlock::end_block`, I
had hoped to make `new` a `const fn` and then just have a `const END_BLOCK` private to mir::build,
but it turns out that constant functions don’t yet support conditionals nor a way to assert.
Add initial version of codegen unit partitioning for incremental compilation.
The task of the partitioning module is to take the complete set of translation items of a crate and produce a set of codegen units from it, where a codegen unit is a named set of (translation-item, linkage) pairs. That is, this module decides which translation item appears in which codegen units with which linkage.
This version only handles the case of partitioning for incremental compilation, not the regular N-codegen units case. In the future the regular case should be handled too, maybe even doing a bit more analysis to intelligently figure out a good partitioning.
One thing that could be improved is the syntax of the codegen unit tests. Right now they still use the compile-fail error specification infrastructure, so everything has to be on one line. Would be nice to be able to format things in a more readable way.
Currently the `rust-std` package produced by rustbuild only contains the
standard library plus libtest, but the makefiles actually produce a `rust-std`
package with all known target libraries (including libsyntax, librustc, etc).
Tweak the behavior so the dependencies of the `dist-docs` step in rustbuild
depend on the compiler libraries as well (so that they're all packaged).
Closes#32984
Reading this, one item stood out a bit. Small improvements here.
. ‘Compile-time’ is not a noun, ‘compilation time’ was meant;
. Mathematical formulas are best not rendered as code;
. Use the same tense as in other items.
alloc_system: Handle failure properly
The Unix implementation was incorrectly handling failure for reallocation of
over-aligned types by not checking for NULL.
Closes#32993
Restore trait impl docs
Currently, documentation on methods in trait implementations doesn't get rendered. This changes that; trait implementations have all documentation associated with impl items displayed (documentation from the trait definition is ignored).
Fixes#24838Fixes#26871
Doc fix: Update Cargo.toml in book/getting-started
The Cargo.toml mentioned in book/getting-started
is missing the section called `[dependencies]`
fixes https://github.com/rust-lang/rust/issues/32928
rustbuild: Verify sha256 of downloaded tarballs
Here's a quick first pass at this.
I don't use Python often enough to claim that this is totally Pythonic. I've left off some (almost certainly unnecessary) error handling regarding opening and processing files. The whole tarball is read into memory to calculate the hash, but the file isn't *so* large so that should be fine. I don't care for the output from `raise RuntimeError`, but that's how `run()` does it so I'm following precedent.
Tested by manually changing the value of `expected`, and by modifying the tarball then forcing `rustc_out_of_date()`. Both cases tripped the error.
Closes https://github.com/rust-lang/rust/issues/32902
Fix macro hygiene bug
This fixes#32922 (EDIT: and fixes#31856), macro hygiene bugs.
It is a [breaking-change]. For example, the following would break:
```rust
fn main() {
let x = true;
macro_rules! foo { () => {
let x = 0;
macro_rules! bar { () => {x} }
let _: bool = bar!();
//^ `bar!()` used to resolve the first `x` (a bool),
//| but will now resolve to the second x (an i32).
}}
foo! {};
}
```
r? @nrc
Extends rustdoc on how to caputure output
- The documentation is quite about how to caputure a process' output when using
` std::process::Child::wait_with_output()`.
- This PR adds an example for this particular use case.
cargotest: Put output in build directory
Right now cargotest uses `TempDir` to place output into the system temp
directory, but unfortunately this means that if the process is interrupted then
it'll leak the directory and that'll never get cleaned up. One of our bots
filled up its disk space and there were 20 cargotest directories lying around so
seems prudent to clean them up!
By putting the output in the build directory it should ensure that we don't leak
too many extra builds.
The `Vec::truncate` method does not panic if the length argument is greater than
the vector's current length, but `String::truncate` will indeed panic. This
semantic difference can be a bit jarring (e.g. #32717), and after some
discussion the libs team concluded that although this can technically be a
breaking change it is almost undoubtedly not so in practice.
This commit changes the semantics of `String::truncate` to be a noop if
`new_len` is greater than the length of the current string.
Closes#32717
Right now cargotest uses `TempDir` to place output into the system temp
directory, but unfortunately this means that if the process is interrupted then
it'll leak the directory and that'll never get cleaned up. One of our bots
filled up its disk space and there were 20 cargotest directories lying around so
seems prudent to clean them up!
By putting the output in the build directory it should ensure that we don't leak
too many extra builds.
rustbuild: Fix handling of the bootstrap key
Bring the calculation logic in line with the makefiles and also set the
RUSTC_BOOTSTRAP_KEY environment variable to enable the bootstrap on the stable
compiler.
We don't want to render default item docs but previously
`doctraititem` naively delegated to the trait definition in those
cases.
Updated tests to also check that this doesn't strip default item
docs from the trait definition.
collections: Add slice::binary_search_by_key
This method adds to the family of `_by_key` methods, and is the
counterpart of `slice::sort_by_key`. It was mentioned on #30423 but
was not implemented at that time.
Refs #30423
In `test/rustdoc/manual_impl.rs` there are now three structs:
* S1 implements and documents required method `a_method`.
* S2 implements and documents `a_method` as well as provided
method `b_method`.
* S3 implements `a_method` and `b_method`, but only documents
`b_method`.
For a struct, we want the rendered trait impls to include documentation
if and only if it appears on the trait implementation itself
(since users can just go to the trait definition for anything not
covered in the impl docs). This means we expect:
* S1, S2, and S3 to all include top-level trait impl docs.
* S1, S2, and S3 to exclude all trait definition docs.
* S1 to show impl docs for `a_method`.
* S2 to show impl docs for `a_method` and `b_method`.
* S3 to show impl docs for `b_method`.
These tests cover those cases.
Deduplicate libraries on hash instead of filename.
Removes the need for canonicalization to prevent #12459.
(Now with passing tests!)
Canonicalization breaks certain environments where the libraries are symlinks to files that don't end in .rlib (e.g. /remote/cas/$HASH).
This modifies our listing of tiered platforms a few ways:
* All lists are alphabetized based on target now
* Lots of targets are moved up to "Tier 2" as we're gating on all these builds
and official releases are provided (and installable via rustup).
* A few targets now list having a compiler + cargo now as well.
No more platforms have been moved up to Tier 1 at this time, however. The only
real candidate is ``x86_64-unknown-linux-musl`, but that's not *quite* to a tier
1 level of quality just yet so let's hold off for another release or so to iron
it out a bit.
