This reverts commit 7f1d1c6d9a.
The original commit was created because mdBook and rustdoc had
different generation algorithms for header links; now with
https://github.com/rust-lang/rust/pull/39966 , the algorithms
are the same. So let's undo this change.
... when I came across this problem, I said "eh, this isn't fun,
but it doesn't take that long." I probably should have just actually
taken the time to fix upstream, given that they were amenable. Oh
well!
Update mdbook version
This version of mdbook includes
https://github.com/azerupi/mdBook/pull/207 , which is needed so that
we can start doing linkchecker on the various books.
- Add a small section to generics.md to explain how ambiguities in type
inference can be resolved using the ::<> syntax.
- Add links from syntax-index.md and iterators.md.
- Minor edits to iterators.md and structs.md.
Docs: Better explanation of return values for min, max functions for the Iterator trait
Added an explanation that `None` is returned if an iterator is empty.
Also added examples for `max` and `min`. I chose not to add examples for other functions like `max_by_key` etc. so that the examples stay concised and focused on the main functionality.
Fixup String::split_off documentation
1. Clarify that `String::split_off` returns one string and modifies self in-place. The documentation implied that it returns two new strings.
2. Make the documentation mirror `Vec::split_off`.
Correct a typo in procedural macros chapter of the Book.
A simple and short correction for procedural macros chapter of the Rust Programming Language Book.
erase late bound regions in `get_vtable_methods()`
Higher-ranked object types can otherwise cause late-bound regions to
sneak into the substs, leading to the false conclusion that some method
is unreachable.
r? @arielb1, who wrote the heart of this patch anyhow
Fixes#39292
[MIR] Make InlineAsm a Statement
Previously InlineAsm was an Rvalue, but its semantics doesn't really match the semantics of an
Rvalue - rather it behaves more like a Statement.
r? @nikomatsakis you wanted this to happen
rustc: Link statically to the MSVCRT
This commit changes all MSVC rustc binaries to be compiled with
`-C target-feature=+crt-static` to link statically against the MSVCRT instead of
dynamically (as it does today). This also necessitates compiling LLVM in a
different fashion, ensuring it's compiled with `/MT` instead of `/MD`.
cc #37406
These are some samples that I have been focusing on improving over
time. In this PR, I mainly want to stem the bleeding where we in some
cases we show an error that gives you no possible way to divine the
problem.
Fix for bootstrapping on NixOS
NixOS puts Linux's dynamic loader in wierd place. Detect when we're on NixOS and patch the downloaded bootstrap executables appropriately.
appveyor: Move MSVC dist builds to their own builder
In the long run we want to separate out the dist builders from the test
builders. This provides us leeway to expand the dist builders with more tools
(e.g. Cargo and the RLS) without impacting cycle times.
Currently the Travis dist builders double-up the platforms they provide builds
for, so I figured we could try that out for MSVC as well. This commit adds a new
AppVeyor builder which runs a dist for all the MSVC targets:
* x86_64-pc-windows-msvc
* i686-pc-windows-msvc
* i586-pc-windows-msvc
If this takes too long and/or times out we'll need to split this up. In any case
we're going to need more capacity from AppVeyor no matter what becaue the two
pc-windows-gnu targets can't cross compile so we need at least 2 more builders
no matter what.
1. Clarify that `String::split_off` returns one string and modifies self
in-place. The documentation implied that it returns two new strings.
2. Make the documentation mirror `Vec::split_off`.
Adaptive hashmap implementation
All credits to @pczarn who wrote https://github.com/rust-lang/rfcs/pull/1796 and https://github.com/contain-rs/hashmap2/pull/5
**Background**
Rust std lib hashmap puts a strong emphasis on security, we did some improvements in https://github.com/rust-lang/rust/pull/37470 but in some very specific cases and for non-default hashers it's still vulnerable (see #36481).
This is a simplified version of https://github.com/rust-lang/rfcs/pull/1796 proposal sans switching hashers on the fly and other things that require an RFC process and further decisions. I think this part has great potential by itself.
**Proposal**
This PR adds code checking for extra long probe and shifts lengths (see code comments and https://github.com/rust-lang/rfcs/pull/1796 for details), when those are encountered the hashmap will grow (even if the capacity limit is not reached yet) _greatly_ attenuating the degenerate performance case.
We need a lower bound on the minimum occupancy that may trigger the early resize, otherwise in extreme cases it's possible to turn the CPU attack into a memory attack. The PR code puts that lower bound at half of the max occupancy (defined by ResizePolicy). This reduces the protection (it could potentially be exploited between 0-50% occupancy) but makes it completely safe.
**Drawbacks**
* May interact badly with poor hashers. Maps using those may not use the desired capacity.
* It adds 2-3 branches to the common insert path, luckily those are highly predictable and there's room to shave some in future patches.
* May complicate exposure of ResizePolicy in the future as the constants are a function of the fill factor.
**Example**
Example code that exploit the exposure of iteration order and weak hasher.
```
const MERGE: usize = 10_000usize;
#[bench]
fn merge_dos(b: &mut Bencher) {
let first_map: $hashmap<usize, usize, FnvBuilder> = (0..MERGE).map(|i| (i, i)).collect();
let second_map: $hashmap<usize, usize, FnvBuilder> = (MERGE..MERGE * 2).map(|i| (i, i)).collect();
b.iter(|| {
let mut merged = first_map.clone();
for (&k, &v) in &second_map {
merged.insert(k, v);
}
::test::black_box(merged);
});
}
```
_91 is stdlib and _ad is patched (the end capacity in both cases is the same)
```
running 2 tests
test _91::merge_dos ... bench: 47,311,843 ns/iter (+/- 2,040,302)
test _ad::merge_dos ... bench: 599,099 ns/iter (+/- 83,270)
```
In the long run we want to separate out the dist builders from the test
builders. This provides us leeway to expand the dist builders with more tools
(e.g. Cargo and the RLS) without impacting cycle times.
Currently the Travis dist builders double-up the platforms they provide builds
for, so I figured we could try that out for MSVC as well. This commit adds a new
AppVeyor builder which runs a dist for all the MSVC targets:
* x86_64-pc-windows-msvc
* i686-pc-windows-msvc
* i586-pc-windows-msvc
If this takes too long and/or times out we'll need to split this up. In any case
we're going to need more capacity from AppVeyor no matter what becaue the two
pc-windows-gnu targets can't cross compile so we need at least 2 more builders
no matter what.
Higher-ranked object types can otherwise cause late-bound regions to
sneak into the substs, leading to the false conclusion that some method
is unreachable. The heart of this patch is from @arielb1.
travis: Disable source tarballs on most builders
Currently we create a source tarball on almost all of the `DEPLOY=1` builders
but this has the adverse side effect of all source tarballs overriding
themselves in the S3 bucket. Normally this is ok but unfortunately a source
tarball created on Windows is not buildable on Unix.
On Windows the vendored sources contain paths with `\` characters in them which
when interpreted on Unix end up in "file not found" errors.
Instead of this overwriting behavior, whitelist just one linux builder for
producing tarballs and avoid producing tarballs on all other hosts.
