rust/src/libstd/sys/unix/mod.rs, branch 1.27.1

Prevent EPIPE causing ICEs in rustc and rustdoc

2018-04-11T10:05:13+00:00

std: Avoid use of `libc` in portable modules

2017-11-09T15:56:44+00:00

This commit removes usage of the `libc` crate in "portable" modules like those at the top level and `sys_common`. Instead common types like `*mut u8` or `u32` are used instead of `*mut c_void` or `c_int` as well as switching to platform-specific functions like `sys::strlen` instead of `libc::strlen`.

std: Move the `cmath` module into the `sys` module

2017-11-09T04:42:23+00:00

This commit moves the `f32::cmath` and `f64::cmath` modules into the `sys` module. Note that these are not publicly exported modules, simply implementation details. These modules are already platform-specific with shims on MSVC and this is mostly just a reflection of that reality. This should also help cut down on `#[cfg]` traffic if platforms are brought on which don't directly support these functions.

std: Remove `rand` crate and module

2017-11-09T04:41:17+00:00

This commit removes the `rand` crate from the standard library facade as well as the `__rand` module in the standard library. Neither of these were used in any meaningful way in the standard library itself. The only need for randomness in libstd is to initialize the thread-local keys of a `HashMap`, and that unconditionally used `OsRng` defined in the standard library anyway. The cruft of the `rand` crate and the extra `rand` support in the standard library makes libstd slightly more difficult to port to new platforms, namely WebAssembly which doesn't have any randomness at all (without interfacing with JS). The purpose of this commit is to clarify and streamline randomness in libstd, focusing on how it's only required in one location, hashmap seeds. Note that the `rand` crate out of tree has almost always been a drop-in replacement for the `rand` crate in-tree, so any usage (accidental or purposeful) of the crate in-tree should switch to the `rand` crate on crates.io. This then also has the further benefit of avoiding duplication (mostly) between the two crates!

Remove nacl from libstd

2017-10-05T03:01:41+00:00

Re-enable networking module fo rL4Re

2017-09-08T12:36:56+00:00

As suggested in the discussion of PR #43972, std should provide a uniform API to all platforms. Since there's no networking on L4Re, this now is a module in `sys::net` providing types and functions/methods returning an error for each action.

Add modifications needed for L4re in libstd

2017-09-08T12:36:56+00:00

This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re). A target for the L4Re was introduced in commit: c151220a84e40b65e45308cc0f3bbea4466d3acf In many aspects implementations for linux also apply for the L4Re microkernel. Two uncommon characteristics had to be resolved: * L4Re has no network funktionality * L4Re has a maximum stacksize of 1Mb for threads Co-authored-by: Sebastian Humenda

Match c_char definitions and enable signal reset for L4Re

2017-09-08T12:36:56+00:00

* Match definition of c_char in os/raw.rs with the libc definition Due to historic reasons, os/raw.rs redefines types for c_char from libc, but these didn't match. Now they do :). * Enable signal reset on exec for L4Re L4Re has full signal emulation and hence it needs to reset the signal set of the child with sigemptyset. However, gid and uid should *not* be set.

Exposed all platform-specific documentation.

2017-08-10T05:43:59+00:00

rustc: Implement the #[global_allocator] attribute

2017-07-05T21:37:01+00:00

This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389