When getaddrinfo returns EAI_SYSTEM retrieve actual error from errno.
Fixes issue #36546. This change also updates libc to earliest version
that includes EAI_SYSTEM constant.
Previously, in cases where `EAI_SYSTEM` has been returned from getaddrinfo, the
resulting `io::Error` would be broadly described as "System error":
Error { repr: Custom(Custom { kind: Other, error: StringError("failed to lookup address information: System error") }) }
After change a more detailed error is crated based on particular value of
errno, for example:
Error { repr: Os { code: 64, message: "Machine is not on the network" } }
The only downside is that the prefix "failed to lookup address information" is
no longer included in the error message.
librustdoc refactoring and cleanup.
See each commit for more information. Biggest changes here is the addition of a `passes` module and each pass now lives in its own submodule.
Haiku: Initial work at OS support
These changes should be non-invasive to non-Haiku platforms. These patches were hand reworked from Neil's original Rust 1.9.0 patches. I've done some style cleanup and design updates along the way.
There are a few small additional patches to libc, rust-installer and compiler-rt that will be submitted once this one is accepted.
Haiku can be compiled on Linux, and a full gcc cross-compiler with a Haiku target is available, which means bootstrapping should be fairly easy. The patches here have already successfully bootstrapped under our haiku x86_gcc2 architecture. http://rust-on-haiku.com/wiki/PortingRust
I'll be focusing on our more modern gcc5 x86 and x86 architectures for now.
As for support, we're not seeking official support for now. We understand Haiku isn't a top-tier OS choice, however having these patches upstream greatly reduces the amount of patchwork we have to do. Mesa has Haiku code upstream, and we submit patches to keep it going. Mesa doesn't test on Haiku and we're ok with that :-)
rustdoc css: Put `where` in trait listings on a new line
This is about the gray area at the top of a trait's documentation page,
that lists all methods and their signatures. A big trait page like
Iterator is very crowded without this tweak.
rustbuild: Print out all build steps when --verbose
These helped me debug some problems with the asmjs target. It's just vomiting debug representations, so not the prettiest stuff.
r? @alexcrichton
rustdoc: implement --sysroot
with the same semantics as rustc. This let us build documentation for a
crate that depends on a custom sysroot.
r? @alexcrichton
cc @cbiffle
rustc: implement -C link-arg
this flag lets you pass a _single_ argument to the linker but can be
used _repeatedly_. For example, instead of using:
```
rustc -C link-args='-l bar' (..)
```
you could write
```
rustc -C link-arg='-l' -C link-arg='bar' (..)
```
This new flag can be used with RUSTFLAGS where `-C link-args` has
problems with "nested" spaces:
```
RUSTFLAGS='-C link-args="-Tlayout.ld -nostartfiles"'
```
This passes three arguments to rustc: `-C` `link-args="-Tlayout.ld` and
`-nostartfiles"` to `rustc`. That's not what we meant. But this does
what we want:
```
RUSTFLAGS='-C link-arg=-Tlayout.ld -C link-arg=-nostartfiles`
```
cc rust-lang/rfcs#1509
r? @alexcrichton
cc @Zoxc
This needs a test. Any suggestion?
Docs: Update to "Getting Started" section
I came across #34523 and wanted to suggest a solution. See commit for details.
It seemed like a good place to start contributing, let me know if I did anything wrong 😇
Change error message for intrinsic signature.
Makes it so the signature of the intrinsic in the user's code is
"found," while the signature that rustc knows about is "expected."
Before this patch, the code
```
extern "platform-intrinsic" {
fn x86_mm_movemask_ps() -> i32;
}
```
would give the error
```
error[E0444]: platform-specific intrinsic has invalid number of arguments: found 1, expected 0
--> test.rs:4:5
|
4 | fn x86_mm_movemask_ps() -> i32;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
After this patch, it says "found 0, expected 1".
Don't allocate during default HashSet creation.
The following `HashMap` creation functions don't allocate heap storage for elements.
```
HashMap::new()
HashMap::default()
HashMap::with_hasher()
```
This is good, because it's surprisingly common to create a HashMap and never
use it. So that case should be cheap.
However, `HashSet` does not have the same behaviour. The corresponding creation
functions *do* allocate heap storage for the default number of non-zero
elements (which is 32 slots for 29 elements).
```
HashMap::new()
HashMap::default()
HashMap::with_hasher()
```
This commit gives `HashSet` the same behaviour as `HashMap`, by simply calling
the corresponding `HashMap` functions (something `HashSet` already does for
`with_capacity` and `with_capacity_and_hasher`). It also reformats one existing
`HashSet` construction to use a consistent single-line format.
This speeds up rustc itself by 1.01--1.04x on most of the non-tiny
rustc-benchmarks.
