Preparation for allocator aware `Box`
This cleans up the `Box` code a bit, and uses `Box::from_raw(ptr)` instead of `Box(ptr)`.
Additionally, `box_free` and `exchange_malloc` now uses the `AllocRef` trait and a comment was added on how `box_free` is tied to `Box`.
This a preparation for an upcoming PR, which makes `Box` aware of an allocator.
r? @Amanieu
Add missing `_zeroed` varants to `AllocRef`
The majority of the allocator wg has decided to add the missing `_zeroed` variants to `AllocRef`:
> these should be added since they can be efficiently implemented with the `mremap` system call on Linux. `mremap` allows you to move/grow/shrink a memory mapping, and any new pages added for growth are guaranteed to be zeroed.
>
> If `AllocRef` does not have these methods then the user will have to manually write zeroes to the added memory since the API makes no guarantees on their contents.
For the full discussion please see https://github.com/rust-lang/wg-allocators/issues/14.
This PR provides default implementations for `realloc_zeroed`, `alloc_excess_zeroed`, `realloc_excess_zeroed`, and `grow_in_place_zeroed`.
r? @Amanieu
Remove common usage pattern from `AllocRef`
This removes the common usage patterns from `AllocRef`:
- `alloc_one`
- `dealloc_one`
- `alloc_array`
- `realloc_array`
- `dealloc_array`
Actually, they add nothing to `AllocRef` except a [convenience wrapper around `Layout` and other methods in this trait](https://doc.rust-lang.org/1.41.0/src/core/alloc.rs.html#1076-1240) but have a major flaw: The documentation of `AllocRefs` notes, that
> some higher-level allocation methods (`alloc_one`, `alloc_array`) are well-defined on zero-sized types and can optionally support them: it is left up to the implementor whether to return `Err`, or to return `Ok` with some pointer.
With the current API, `GlobalAlloc` does not have those methods, so they cannot be overridden for `liballoc::Global`, which means that even if the global allocator would support zero-sized allocations, `alloc_one`, `alloc_array`, and `realloc_array` for `liballoc::Global` will error, while calling `alloc` with a zeroed-size `Layout` could succeed. Even worse: allocating with `alloc` and deallocating with `dealloc_{one,array}` could end up with not calling `dealloc` at all!
For the full discussion please see https://github.com/rust-lang/wg-allocators/issues/18
r? @Amanieu
Python script PEP8 style guide space formatting and minor Python source cleanup
This PR includes the following changes in the Python sources based on a flake8 3.7.9 (mccabe: 0.6.1, pycodestyle: 2.5.0, pyflakes: 2.1.1) CPython 3.7.6 on Darwin lint:
- PEP8 style guide spacing updates *without* line length changes
- removal of unused local variable assignments in context managers and exception handling
- removal of unused Python import statements
- removal of unnecessary semicolons
Test failure of unchecked arithmetic intrinsics in const eval
Test that the unchecked arithmetic intrinsics that were made unstably const in #68809 emit an error during const-eval if given invalid input.
Addresses [this comment](https://github.com/rust-lang/rust/pull/68809#discussion_r375753066).
r? @RalfJung
[experiment] Support linking from a .rlink file
Flag `-Z no-link` was previously introduced, which allows creating an `.rlink` file to perform compilation without linking. This change enables linking from an `.rlink` file.
Part of Issue #64191
This makes it faster and also changes it to a safe function. (Thanks to
Michael Woerister for the suggestion.) `load_int_le!` is also no longer
necessary.
When encountering E0212, detect whether this is a representable case or
not, i.e. if it's happening on an `fn` or on an ADT. If the former,
provide a structured suggestion, otherwise note that this can't be
represented in Rust.