| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix various typos in doc comments
|
|
Speed up String::from_utf16
Collecting into a `Result` is idiomatic, but not necessarily fast due to rustc not being able to preallocate for the resulting collection. This is fine in case of an error, but IMO we should optimize for the common case, i.e. a successful conversion.
This changes the behavior of `String::from_utf16` from collecting into a `Result` to pushing to a preallocated `String` in a loop.
According to [my simple benchmark](https://gist.github.com/ljedrz/953a3fb74058806519bd4d640d6f65ae) this change makes `String::from_utf16` around **twice** as fast.
|
|
|
|
global allocators: add a few comments
These comments answer some questions that came up when I tried to understand how the control flow works for the global allocator, `Global` and `System`.
r? @alexcrichton
|
|
string: Add documentation for `From` impls
Hi this is part of #51430. I'm a first time contributor, so I started with a small task adding a bit of documentation for From impls.
|
|
add FromIterator<A> to Box<[A]>
|
|
Format BtreeMap::range_mut example
Before:
After:
|
|
|
|
|
|
This commit deletes the `alloc_system` crate from the standard
distribution. This unstable crate is no longer needed in the modern
stable global allocator world, but rather its functionality is folded
directly into the standard library. The standard library was already the
only stable location to access this crate, and as a result this should
not affect any stable code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Rounds allocation layout up to a multiple of alignment
* Adds a convenience method `Layout::pad_to_align` to perform rounding
|
|
Add tracking issue for Layout methods (and some API changes)
These methods are already useful when used with the stable global allocator API (stabilized in #51241).
```rust
pub fn align_to(&self, align: usize) -> Result<Layout, LayoutErr>;
pub fn padding_needed_for(&self, align: usize) -> usize;
pub fn repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>;
pub fn extend(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>;
pub fn repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>;
pub fn extend_packed(&self, next: Layout) -> Result<Layout, LayoutErr>;
pub fn array<T>(n: usize) -> Result<Layout, LayoutErr>;
```
cc #32838
r? @SimonSapin
|
|
refactor: use shorthand fields
refactor: use shorthand for single fields everywhere (excluding tests).
|
|
|
|
|
|
|
|
Fix undefined behavior in Rc/Arc allocation
Manually calculate allocation layout for `Rc`/`Arc` to avoid undefined behavior
Closes #54908
|
|
Manually calculate allocation layout for `Rc`/`Arc` to avoid undefined behavior
|
|
Remove the `alloc_jemalloc` crate
This commit removes the `alloc_jemalloc` crate from the standard library and all related configuration. We will no longer be shipping this unstable crate. Rationale for this is provided on https://github.com/rust-lang/rust/issues/36963 and the many linked issues, but I can inline rationale here if desired!
We currently rely on jemalloc for increased perf in the Rust compiler, however. [This perf run shows](https://perf.rust-lang.org/compare.html?start=74ff7dcb1388e60a613cd6050bcd372a3cc4998b&end=7e7928dc0340d79b404e93f0c79eb4b946c1d669&stat=wall-time) that if we switch to glibc 2.23's allocator that it's slower than jemalloc across many benchmarks. [This perf run, however](https://perf.rust-lang.org/compare.html?start=22cc2ae8057d14e980b7c784e1eb2eee26b59e7d&end=10c95ccfa7a7adc12f4e608621ca29f9b98eed29), shows that if we use `jemalloc-sys` from crates.io then rustc actually gets faster across all benchmarks! (presumably because it has a more recent version of jemalloc than our submodule).
As a result, it's expected that this doesn't regress any code (as it's just removing an unstable crate) and it should actually improve rustc performance because it updates jemalloc.
Closes #36963
|
|
This commit removes all jemalloc related submodules, configuration, etc,
from the bootstrap, from the standard library, and from the compiler.
This will be followed up with a change to use jemalloc specifically as
part of rustc on blessed platforms.
|
|
Rename `CoerceSized` to `DispatchFromDyn`, and reverse the direction so that, for example, you write
```
impl<T: Unsize<U>, U> DispatchFromDyn<*const U> for *const T {}
```
instead of
```
impl<T: Unsize<U>, U> DispatchFromDyn<*const T> for *const U {}
```
this way the trait is really just a subset of `CoerceUnsized`.
The checks in object_safety.rs are updated for the new trait, and some documentation and method names in there are updated for the new trait name — e.g. `receiver_is_coercible` is now called `receiver_is_dispatchable`. Since the trait now works in the opposite direction, some code had to updated here for that too.
I did not update the error messages for invalid `CoerceSized` (now `DispatchFromDyn`) implementations, except to find/replace `CoerceSized` with `DispatchFromDyn`. Will ask for suggestions in the PR thread.
|
|
This will make receiver types like `Rc<Self>` and `Pin<&mut Self>`
object-safe.
|
|
* Also update the bootstrap compiler
* Update cargo to 1.32.0
* Clean out stage0 annotations
|
|
|
|
msp430: remove the whole Atomic* API
PR #51953 enabled the Atomic*.{load,store} API on MSP430. Unfortunately,
the LLVM backend doesn't currently support those atomic operations, so this
commit removes the API and leaves instructions on how and when to enable it
in the future.
the second fixes compiling liballoc for msp430
closes #54511
r? @alexcrichton
cc @chernomor @awygle @cr1901 @pftbest
|
|
|
|
remove unused variable i in example String::with_capacity()
|
|
|
|
Fixes #55177
|
|
Fixes #47115
|
|
Add slice::rchunks(), rchunks_mut(), rchunks_exact() and rchunks_exact_mut()
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
----
The new iterators were motivated by a [comment](https://github.com/rust-lang/rust/issues/47115#issuecomment-424141121) by @DutchGhost.
~~~This currently includes the commits from https://github.com/rust-lang/rust/pull/54537 to not have to rename things twice or have merge conflicts. I'll force-push a new version of the branch ones those are in master.~~~
Also the stabilization tracking issue is just some number right now. I'll create the corresponding issue once this is reviewed and otherwise mergeable.
cc @DutchGhost
|
|
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
See #55177 for the tracking issue
|
|
doc std::fmt: the Python inspiration is already mentioned in precedin…
…g paragraph
|
|
doc: fix sentence structure in std::fmt
|
|
|
|
|
|
In the comments of (closed, defunct) pull request #54884, Mazdak
"Centril" Farrokhzad noted that must-use annotations didn't work on an
associated function (what other communities might call a "static
method"). Subsequent logging revealed that in this case we have a
`Def::Method`, whereas the lint pass was only matching on
`Def::Fn`. (One could argue that those def-names are thereby
misleading—must-use for self-ful methods have always worked—but
documenting or reworking that can be left to another day.)
|
|
Fix slice's benchmarks
Fixes #54013.
|
|
Add doc comments about safest way to initialize a vector of zeros
This adds more information about the vec! macro as discussed in #54628. I think this is a good starting point, but I think additional detail is needed so that we can explain why vec! is safer than the alternatives.
|
|
Use MaybeUninit in liballoc
All code by @japaric. This is a re-submission of a part of https://github.com/rust-lang/rust/pull/53508 that hopefully does not regress performance.
|
|
Fixes #54013.
|
|
|
|
liballoc: mark str.to_owned() and String::from(&str) as #[inline].
Fixes #53681
|
|
|
