rust/src/libstd/alloc.rs, branch 1.31.0

Bump to 1.31.0 and bootstrap from 1.30 beta

2018-09-28T03:52:53+00:00

rustc: Continue to tweak "std internal symbols"

2018-08-26T23:34:14+00:00

In investigating [an issue][1] with `panic_implementation` defined in an executable that's optimized I once again got to rethinking a bit about the `rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of been non-stop tweaking these items ever since their inception, and this continues to the trend. The crux of the bug was that in the reachability we have a [different branch][2] for non-library builds which meant that weak lang items (and std internal symbols) weren't considered reachable, causing them to get eliminiated by ThinLTO passes. The fix was to basically tweak that branch to consider these symbols to ensure that they're propagated all the way to the linker. Along the way I've attempted to erode the distinction between std internal symbols and weak lang items by having weak lang items automatically configure fields of `CodegenFnAttrs`. That way most code no longer even considers weak lang items and they're simply considered normal functions with attributes about the ABI. In the end this fixes the final comment of #51342 [1]: https://github.com/rust-lang/rust/issues/51342#issuecomment-414368019 [2]: https://github.com/rust-lang/rust/blob/35bf1ae25799a4e62131159f052e0a3cbd27c960/src/librustc/middle/reachable.rs#L225-L238

Switch to bootstrapping from 1.29 beta

2018-08-01T17:59:08+00:00

Implement #[alloc_error_handler]

2018-07-09T21:13:24+00:00

This to-be-stable attribute is equivalent to `#[lang = "oom"]`. It is required when using the alloc crate without the std crate. It is called by `handle_alloc_error`, which is in turned called by "infallible" allocations APIs such as `Vec::push`.

Remove `extern` on the `pub fn rust_oom` lang item in libstd, to match ABI of the declaration in liballoc

2018-07-09T21:13:24+00:00

This turned out to be important on Windows. Calling `handle_alloc_error(Layout::new::<[u8; 42]>())` caused: ``` Exception thrown at 0x00007FF7C70DC399 in a.exe: 0xC0000005: Access violation reading location 0x000000000000002A. ``` 0x2A equals 42, so it looks like the `Layout::size` field of type `usize` was interpreted as a pointer to read from.

Fix inconsequential typo in GlobalAlloc doc example

2018-06-29T02:12:02+00:00

Rename OOM to allocation error

2018-06-18T19:41:24+00:00

The acronym is not descriptive unless one has seen it before. * Rename the `oom` function to `handle_alloc_error`. It was **stabilized in 1.28**, so if we do this at all we need to land it this cycle. * Rename `set_oom_hook` to `set_alloc_error_hook` * Rename `take_oom_hook` to `take_alloc_error_hook` Bikeshed: `alloc` v.s. `allocator`, `error` v.s. `failure`

Move Unstable Book sections for #[global_allocator] and System to std::alloc docs

2018-06-11T20:48:57+00:00

Stabilize the `System` allocator

2018-06-11T20:48:39+00:00

Move set_oom_hook and take_oom_hook to a dedicated tracking issue

2018-06-11T20:48:39+00:00