| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The expression `&s[..i]` in general can panic if `i` is out of bounds or not on
a character boundary for a string, and this caused the codegen for
`Formatter::pad` to be a bit larger than it otherwise needed to be. This commit
replaces this with `s.get(..i).unwrap_or(&s)` which while having different
behavior if `i` is out of bounds has a much smaller code footprint and otherwise
avoids the need for `unsafe` code.
|
|
Create one canonical location which panics with "capacity overflow" instead of
having many. This reduces the size of a `panic!("{}", 1)` binary on wasm from
34k to 17k.
|
|
This commit applies a few code size optimizations for the wasm target to
the standard library, namely around panics. We notably know that in most
configurations it's impossible for us to print anything in
wasm32-unknown-unknown so we can skip larger portions of panicking that
are otherwise simply informative. This allows us to get quite a nice
size reduction.
Finally we can also tweak where the allocation happens for the
`Box<Any>` that we panic with. By only allocating once unwinding starts
we can reduce the size of a panicking wasm module from 44k to 350 bytes.
|
|
Add GlobalAlloc trait + tweaks for initial stabilization
This is the outcome of discussion at the Rust All Hands in Berlin. The high-level goal is stabilizing sooner rather than later the ability to [change the global allocator](https://github.com/rust-lang/rust/issues/27389), as well as allocating memory without abusing `Vec::with_capacity` + `mem::forget`.
Since we’re not ready to settle every detail of the `Alloc` trait for the purpose of collections that are generic over the allocator type (for example the possibility of a separate trait for deallocation only, and what that would look like exactly), we propose introducing separately **a new `GlobalAlloc` trait**, for use with the `#[global_allocator]` attribute.
We also propose a number of changes to existing APIs. They are batched in this one PR in order to minimize disruption to Nightly users.
The plan for initial stabilization is detailed in the tracking issue https://github.com/rust-lang/rust/issues/49668.
CC @rust-lang/libs, @glandium
## Immediate breaking changes to unstable features
* For pointers to allocated memory, change the pointed type from `u8` to `Opaque`, a new public [extern type](https://github.com/rust-lang/rust/issues/43467). Since extern types are not `Sized`, `<*mut _>::offset` cannot be used without first casting to another pointer type. (We hope that extern types can also be stabilized soon.)
* In the `Alloc` trait, change these pointers to `ptr::NonNull` and change the `AllocErr` type to a zero-size struct. This makes return types `Result<ptr::NonNull<Opaque>, AllocErr>` be pointer-sized.
* Instead of a new `Layout`, `realloc` takes only a new size (in addition to the pointer and old `Layout`). Changing the alignment is not supported with `realloc`.
* Change the return type of `Layout::from_size_align` from `Option<Self>` to `Result<Self, LayoutErr>`, with `LayoutErr` a new opaque struct.
* A `static` item registered as the global allocator with the `#[global_allocator]` **must now implement the new `GlobalAlloc` trait** instead of `Alloc`.
## Eventually-breaking changes to unstable features, with a deprecation period
* Rename the respective `heap` modules to `alloc` in the `core`, `alloc`, and `std` crates. (Yes, this does mean that `::alloc::alloc::Alloc::alloc` is a valid path to a trait method if you have `exetrn crate alloc;`)
* Rename the the `Heap` type to `Global`, since it is the entry point for what’s registered with `#[global_allocator]`.
Old names remain available for now, as deprecated `pub use` reexports.
## Backward-compatible changes
* Add a new [extern type](https://github.com/rust-lang/rust/issues/43467) `Opaque`, for use in pointers to allocated memory.
* Add a new `GlobalAlloc` trait shown below. Unlike `Alloc`, it uses bare `*mut Opaque` without `NonNull` or `Result`. NULL in return values indicates an error (of unspecified nature). This is easier to implement on top of `malloc`-like APIs.
* Add impls of `GlobalAlloc` for both the `Global` and `System` types, in addition to existing impls of `Alloc`. This enables calling `GlobalAlloc` methods on the stable channel before `Alloc` is stable. Implementing two traits with identical method names can make some calls ambiguous, but most code is expected to have no more than one of the two traits in scope. Erroneous code like `use std::alloc::Global; #[global_allocator] static A: Global = Global;` (where `Global` is defined to call itself, causing infinite recursion) is not statically prevented by the type system, but we count on it being hard enough to do accidentally and easy enough to diagnose.
```rust
extern {
pub type Opaque;
}
pub unsafe trait GlobalAlloc {
unsafe fn alloc(&self, layout: Layout) -> *mut Opaque;
unsafe fn dealloc(&self, ptr: *mut Opaque, layout: Layout);
unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut Opaque {
// Default impl: self.alloc() and ptr::write_bytes()
}
unsafe fn realloc(&self, ptr: *mut Opaque, old_layout: Layout, new_size: usize) -> *mut Opaque {
// Default impl: self.alloc() and ptr::copy_nonoverlapping() and self.dealloc()
}
fn oom(&self) -> ! {
// intrinsics::abort
}
// More methods with default impls may be added in the future
}
```
## Bikeshed
The tracking issue https://github.com/rust-lang/rust/issues/49668 lists some open questions. If consensus is reached before this PR is merged, changes can be integrated.
|
|
Implement RFC #2169 (Euclidean modulo).
Tracking issue: #49048
|
|
Run rustfmt on build_helper
Using rustfmt 0.4.1-nightly (e784712f 2018-04-09).
|
|
Hygiene 2.0: Avoid comparing fields by name
There are two separate commits here (not counting tests):
- The first one unifies named (`obj.name`) and numeric (`obj.0`) field access expressions in AST and HIR. Before field references in these expressions are resolved it doesn't matter whether the field is named or numeric (it's just a symbol) and 99% of code is common. After field references are resolved we work with
them by index for all fields (see the second commit), so it's again not important whether the field was named or numeric (this includes MIR where all fields were already by index).
(This refactoring actually fixed some bugs in HIR-based borrow checker where borrows through names (`S {
0: ref x }`) and indices (`&s.0`) weren't considered overlapping.)
- The second commit removes all by-name field comparison and instead resolves field references to their indices once, and then uses those resolutions. (There are still a few name comparisons in save-analysis, because save-analysis is weird, but they are made correctly hygienic).
Thus we are fixing a bunch of "secondary" field hygiene bugs (in borrow checker, lints).
Fixes https://github.com/rust-lang/rust/issues/46314
|
|
Ak 44493 infer predicate
**WIP** Implements #44493
Things to do:
- [x] add feature gate and appropriate tests (see [forge](https://forge.rust-lang.org/feature-guide.html) for some details)
- [x] add a unit testing system similar to `#[rustc_variance]`
- [x] to see how, maybe `rg rustc_variance` and take some notes
- [ ] add more tests:
- [x] we need to decide how to handle `struct Foo<'a, T> { x: &'a T::Item }`
- [x] handle explicit predicates on types
- [ ] handle explicit predicates on `dyn Trait` (this could be put off to a follow-up PR)
- [ ] handle explicit predicates on projections (this could be put off to a follow-up PR)
|
|
|
|
|
|
|
|
One was now unused, and `NonNull::new(…).ok_or(AllocErr)` feels short enough
for the few cases that need the other conversion.
|
|
Fixes #49608
|
|
|
|
… now that #[global_allocator] does not define a symbol for it
|
|
This was relevant to `#[global_allocator]`,
which is now based on `GlobalAlloc` trait instead.
|
|
|
|
|
|
Changing the alignment with realloc is not supported.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Inline the definition of `GlobalAlloc` for `dlmalloc` on wasm and don't rely on
usage of unstable features in `dlmalloc` itself.
|
|
|
|
|
|
… since it is the entry point for what’s registered with `#[global_allocator]`
|
|
|
|
|
|
… to make the name `alloc` available.
|
|
|
|
|
|
|
|
|
|
|
|
Resolve them into field indices once and then use those resolutions
+ Fix rebase
|
|
|
|
union, and projection types. added a feature gate and tests for these scenarios.
|
|
Even more thread-safety changes
r? @michaelwoerister
|
|
Deprecate offset_to; switch core&alloc to using offset_from instead
Bonus: might make code than uses `.len()` on slice iterators faster
cc https://github.com/rust-lang/rust/issues/41079
|
|
|
|
Add ok-wrapping to catch blocks, per RFC
Updates the `catch{}` lowering to wrap the result in `Try::from_ok`.
r? @nikomatsakis
Fixes #41414
Fixes #43818
|
|
Implementation of `#[repr(packed(n))]` RFC 1399.
Tracking issue https://github.com/rust-lang/rust/issues/33158.
|
|
Merge the std_unicode crate into the core crate
[The standard library facade](https://github.com/rust-lang/rust/issues/27783) has historically contained a number of crates with different roles, but that number has decreased over time. `rand` and `libc` have moved to crates.io, and [`collections` was merged into `alloc`](https://github.com/rust-lang/rust/pull/42648). Today we have `core` that applies everywhere, `std` that expects a full operating system, and `alloc` in-between that only requires a memory allocator (which can be provided by users)… and `std_unicode`, which doesn’t really have a reason to be separate anymore. It contains functionality based on Unicode data tables that can be large, but as long as relevant functions are not called the tables should be removed from binaries by linkers.
This deprecates the unstable `std_unicode` crate and moves all of its contents into `core`, replacing them with `pub use` reexports. The crate can be removed later. This also removes the `CharExt` trait (replaced with inherent methods in libcore) and `UnicodeStr` trait (merged into `StrExt`). There traits were both unstable and not intended to be used or named directly.
A number of new items are newly-available in libcore and instantly stable there, but only if they were already stable in libstd.
Fixes #49319.
|
|
|
|
|
|
|
