When cross compiling for a new host, we can't actually run the host compiler to
generate its own libs. In theory, however, all stage2 compilers (for any host)
will produce the same libraries, so we just require the build compiler to
produce the necessary host libraries and then we link those into place.
This switches the defaults to ensure that everything is built with the build
compiler rather than the host compiler itself (which we're not guaranteed to be
able to run)
Currently all multi-host builds assume the the build platform can run the
`llvm-config` binary generated for each host platform we're creating a compiler
for. Unfortunately this assumption isn't always true when cross compiling, so we
need to handle this case.
This commit alters the build script of `rustc_llvm` to understand when it's
running an `llvm-config` which is different than the platform we're targeting for.
This commit fixes a longstanding issue with the makefiles where all host
platforms bootstrap themselves. This commit alters the build logic for the
bootstrap to instead only bootstrap the build triple, and all other compilers
are compiled from that one compiler.
The benefit of this change is that we can cross-compile compilers which cannot
run on the build platform. For example our builders could start creating
`arm-unknown-linux-gnueabihf` compilers.
This reduces the amount of bootstrapping we do, reducing the amount of test
coverage, but overall it should largely just end in faster build times for
multi-host compiles as well as enabling a feature which can't be done today.
cc #5258
Also back out keepalive support for TCP since the API is perhaps not
actually what we want. You can't read the interval on Windows, and
we should probably separate the functionality of turning keepalive on
and overriding the interval.
Refinement of paragraph referenced by [this issue](https://github.com/rust-lang/rust/issues/31927).
The paragraph in question had been adjusted already, but I've made some further clarifications which should help with readability and not leave the reader any `dangling pointers`.
These `_post` methods are quite helpful to control lint behavior without storing e.g. block node ids. So here are a few more I believe will be helpful.
r? @Manishearth
For summary descriptions we need the first paragraph (adjacent lines
until a blank line) - but the rendered markdown of a code block did not
leave a blank line in the html and was thus included in the summary line.
Hello.
I've added links for items inside of some stable methods for consistency with existing ones that already have them. Also includes minor formatting fixes.
r? @steveklabnik
When foldings Substs, we map over VecPerParamSpace instances using
EnumeratedItems which does not provide an accurate size_hint()
in its Iterator implementation. This leads to quite a large number or
reallocations. Providing a suitable size_hint() implementation reduces
the time spent in item-bodies checking quite a bit.
```
crate | before | after | ~change
-------|-------------------------
core | 7.28s | 5.44s | -25%
std | 2.07s | 1.88s | -9.2%
syntax | 8.86s | 8.30s | -6.3%
```
These `_post` methods are quite helpful to control lint behavior without storing e.g. block node ids. So here are a few more I believe will be helpful.
r? @Manishearth
Use .copy_from_slice() where applicable
.copy_from_slice() does the same job of .clone_from_slice(), but the
former is explicitly for Copy elements and calls `memcpy` directly, and
thus is it efficient without optimization too.
When foldings Substs, we map over VecPerParamSpace instances using
EnumeratedItems which does not provide an accurate size_hint()
in its Iterator implementation. This leads to quite a large number or
reallocations. Providing a suitable size_hint() implementation reduces
the time spent in item-bodies checking quite a bit.
```
crate | before | after | ~change
-------|-------------------------
core | 7.28s | 5.44s | -25%
std | 2.07s | 1.88s | -9.2%
syntax | 8.86s | 8.30s | -6.3%
```
CryptGenRandom takes a DWORD (u32) for the length so it only supports
writing u32::MAX bytes at a time.
Casting the length from a usize caused truncation meaning the whole
buffer was not always filled.
cc #31841
This is the same as rust-lang-nursery/rand#99. I think it's a good idea to keep the implementations in sync.
r? @alexcrichton
Similar to #31825 where the read/write limits were capped for files, this
implements similar limits when reading/writing networking types. On Unix this
shouldn't affect anything because the write size is already a `usize`, but on
Windows this will cap the read/write amounts to `i32::max_value`.
cc #31841
