This used to be done to avoid inlining impls referencing private items,
but is now unnecessary since we actually check that impls do not
reference non-doc-reachable items.
rustdoc: Only record the same impl once
Due to inlining it is possible to visit the same module multiple times during `<Cache as DocFolder>::fold_crate`, so we keep track of the modules we've already visited.
fixes#33054
r? @alexcrichton
Remove IPV6_V6ONLY functionality
These settings can only be adjusted before bind time, which doesn't make
sense in the current set of functionality. These methods are stable, but
haven't hit a stable release yet.
Closes#33052
[breaking-change]
r? @alexcrichton
Will also need a backport to the beta.
rustbuild: Run all markdown documentation tests
This commit adds support to rustbuild to run all documentation tests, basically
running `rustdoc --test` over all our documentation.
Sanity check Python on OSX for LLDB tests
Two primary changes:
* Don't get past the configure stage if `python` isn't coming from `/usr/bin`
* Call `debugger.Terminate()` to prevent segfaults on newer versions of LLDB.
Closes#32994
port compiletest to use JSON output
This uncovered a lot of bugs in compiletest and also some shortcomings
of our existing JSON output. We had to add information to the JSON
output, such as suggested text and macro backtraces. We also had to fix
various bugs in the existing tests.
Joint work with @jonathandturner.
r? @alexcrichton
Implement `append` for b-trees.
I have finally found time to revive #26227, this time only with an `append` implementation.
The algorithm implemented here is linear in the size of the two b-trees. It firsts creates
a `MergeIter` from the two b-trees and then builds a new b-tree by pushing
key-value pairs from the `MergeIter` into nodes at the right heights.
Three functions for stealing have been added to the implementation of `Handle` as
well as a getter for the height of a `NodeRef`.
The docs have been updated with performance information about `BTreeMap::append` and
the remark about B has been removed now that it is the same for all instances of `BTreeMap`.
cc @gereeter @Gankro @apasel422
configure: Support --disable-option-checking
I'm trying to package Rust for Fedora (this is nothing official (yet)).
The standard RPM packaging process involves running `./configure` with a whole lot of options that are commonly recognized by autotools configure scripts, but not by Rust's one. Since it does not make much sense to support all of this options, I think it would be great to support at least `--disable-option-checking`, so Rust's configure script would not fail.
[The old attempt](https://github.com/fabiand/rust-spec/blob/master/rustc.spec) to package Rust used a sed script (at line 72), but this is not the recommended way to do that.
The example uses integers for the value being iterated over, but the indices
added by `enumerate` are also integers, so I always end up double taking and
thinking harder than I should when parsing the documentation. I also always
forget which order the index and value are in the tuple so I frequently hit this
stumbling block. This commit changes the documentation to iterate over
characters so that it is immediately obvious which part of the tuple is the
index and which is the value.
Due to inlining it is possible to visit the same module multiple times
during `<Cache as DocFolder>::fold_crate`, so we keep track of the
modules we've already visited.
The algorithm implemented here is linear in the size of the two b-trees. It
firsts creates a `MergeIter` from the two b-trees and then builds a new b-tree
by pushing key-value pairs from the `MergeIter` into nodes at the right heights.
Three functions for stealing have been added to the implementation of `Handle` as
well as a getter for the height of a `NodeRef`.
The docs have been updated with performance information about `BTreeMap::append` and
the remark about B has been removed now that it is the same for all instances of `BTreeMap`.
Split core::iter module implementation into parts
Split core::iter module implementation into parts
split iter.rs into a directory of (implementation private) modules.
+ mod (adaptor structs whose private fields need to be available both for them and Iterator
+ iterator (Iterator trait)
+ traits (FromIterator, etc; all traits but Iterator itself)
+ range (range related)
+ sources (Repeat, Once, Empty)
rustdoc: Fix the strip-hidden `ImplStripper`
Instead of stripping impls which reference *stripped* items, we keep impls which reference *retained* items. We do this because when we strip an item we immediately return, and do not recurse into it - leaving the contained items non-stripped from the point of view of the `ImplStripper`.
fixes#33069
r? @alexcrichton
This uncovered a lot of bugs in compiletest and also some shortcomings
of our existing JSON output. We had to add information to the JSON
output, such as suggested text and macro backtraces. We also had to fix
various bugs in the existing tests.
Joint work with jntrnr.
These settings can only be adjusted before bind time, which doesn't make
sense in the current set of functionality. These methods are stable, but
haven't hit a stable release yet.
Closes#33052
[breaking-change]
MIR: Do not require END_BLOCK to always exist
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.
rustbuild: Package librustc & co for cross-hosts
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
Android's [armeabi-v7a ABI][1] guarantees at least VFPv3-d16 hardware FPU
support, so Rust should include this in the default features for the
arm-linux-androideabi target.
[1]: https://developer.android.com/ndk/guides/abis.html
doc: Update our tier support
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.
Compute `target_feature` from LLVM
This is a work-in-progress fix for #31662.
The logic that computes the target features from the command line has been replaced with queries to the `TargetMachine`.
Compute LLVM-agnostic type layouts in rustc.
Layout for monomorphic types, and some polymorphic ones (e.g. `&T` where `T: Sized`),
can now be computed by rustc without involving LLVM in the actual process.
This gives rustc the ability to evaluate `size_of` or `align_of`, as well as obtain field offsets.
MIR-based CTFE will eventually make use of these layouts, as will MIR trans, shortly.
Layout computation also comes with a `[breaking-change]`, or two:
* `"data-layout"` is now mandatory in custom target specifications, reverting the decision from #27076.
This string is needed because it describes endianness, pointer size and alignments for various types.
We have the first two and we could allow tweaking alignments in target specifications.
Or we could also extract the data layout from LLVM and feed it back into rustc.
However, that can vary with the LLVM version, which is fragile and undermines stability.
For built-in targets, I've added a check that the hardcoded data-layout matches LLVM defaults.
* `transmute` calls are checked in a stricter fashion, which fixes#32377
To expand on `transmute`, there are only 2 allowed patterns: between types with statically known sizes and between pointers with the same potentially-unsized "tail" (which determines the type of unsized metadata they use, if any).
If you're affected, my suggestions are:
* try to use casts (and raw pointer deref) instead of transmutes
* *really* try to avoid `transmute` where possible
* if you have a structure, try working on individual fields and unpack/repack the structure instead of transmuting it whole, e.g. `transmute::<RefCell<Box<T>>, RefCell<*mut T>>(x)` doesn't work, but `RefCell::new(Box::into_raw(x.into_inner()))` does (and `Box::into_raw` is just a `transmute`)
