| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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.
|
|
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 :-)
|
|
Fixes issue #36546. This change also updates libc to earliest version
that includes EAI_SYSTEM constant.
|
|
|
|
Report which required build-time environment variable is not set
|
|
The test relies on the undefined behavior, and so may fail in some
circumstances. This can be worked around by stubbing a memory allocator
in the test, but it is a bit of work, and LLVM could still theoretically
eliminate the write of the zero byte in release mode (which is
intended).
So let's just remove the test and mark the function as inline. It
shouldn't be optimized away when inlined into the debug build of user's
code.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
* Hand rebased from Niels original work on 1.9.0
|
|
* Hand rebased from Niels original work on 1.9.0
|
|
Replace 'e.g.' by 'i.e.'
Fixes #36577.
r? @steveklabnik
|
|
strengthen doc warning about CString::from_raw
Saw unsound code using this function on IRC.
|
|
Implement Debug for DirEntry.
None
|
|
Fix outdated Doc Comment on BufReader::seek
A long time ago non-panicking `unwrap` methods were renamed to `into_inner` in this Pull Request: https://github.com/rust-lang/rust/pull/19149
Looks like this doc comment was not updated however.
|
|
Add missing Eq implementations
Part of #36301.
|
|
|
|
A long time ago non-panicking `unwrap` methods were renamed to `into_inner` in this Pull Request: https://github.com/rust-lang/rust/pull/19149
Looks like this doc comment was not updated however.
|
|
|
|
|
|
Add links between format_args! macro and std::fmt::Arguments struct
r? @GuillaumeGomez
|
|
|
|
|
|
* We never want to make guarantees about protecting against attacks.
* "True randomness" is not the right terminology to be using in this
context.
* There is significantly more nuance to the performance of SipHash than
"somewhat slow".
|
|
|
|
doc: make that sound better
|
|
|
|
Add checked operation methods to Duration
Addresses #35774.
|
|
|
|
|
|
|
|
|
|
Add doc examples for std::net::IpAddr construction.
None
|
|
Documentation of what Default does for each type
Addresses #36265
I haven't changed the following types due to doubts:
1)src/libstd/ffi/c_str.rs
2)src/libcore/iter/sources.rs
3)src/libcore/hash/mod.rs
4)src/libcore/hash/mod.rs
5)src/librustc/middle/privacy.rs
r? @steveklabnik
|
|
Replace try! with ?.
|
|
|
|
|
|
|
|
|
|
crate-ify compiler-rt into compiler-builtins
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib
This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.
Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics - this is a [breaking-change]. Users
of the `std` have to do nothing extra as the std crate depends
on compiler-builtins.
Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.
closes #34400
---
r? @alexcrichton
|
|
This commit fixes a test which now needs to explicitly link to the
`compiler_builtins` crate as well as makes the `compiler_builtins` crate
unstable.
|
|
Zero first byte of CString on drop
Hi! This is one more attempt to ameliorate `CString::new("...").unwrap().as_ptr()` problem (related RFC: https://github.com/rust-lang/rfcs/pull/1642).
One of the biggest problems with this code is that it may actually work in practice, so the idea of this PR is to proactively break such invalid code.
Looks like writing a `null` byte at the start of the CString should do the trick, and I think is an affordable cost: zeroing a single byte in `Drop` should be cheap enough compared to actual memory deallocation which would follow.
I would actually prefer to do something like
```Rust
impl Drop for CString {
fn drop(&mut self) {
let pattern = b"CTHULHU FHTAGN ";
let bytes = self.inner[..self.inner.len() - 1];
for (d, s) in bytes.iter_mut().zip(pattern.iter().cycle()) {
*d = *s;
}
}
}
```
because Cthulhu error should be much easier to google, but unfortunately this would be too expensive in release builds, and we can't implement things `cfg(debug_assertions)` conditionally in stdlib.
Not sure if the whole idea or my implementation (I've used ~~`transmute`~~ `mem::unitialized` to workaround move out of Drop thing) makes sense :)
|
