| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Unique pointers and vectors currently contain a reference counting
header when containing a managed pointer.
This `{ ref_count, type_desc, prev, next }` header is not necessary and
not a sensible foundation for tracing. It adds needless complexity to
library code and is responsible for breakage in places where the branch
has been left out.
The `borrow_offset` field can now be removed from `TyDesc` along with
the associated handling in the compiler.
Closes #9510
Closes #11533
|
|
The failure functions are generic, meaning they're candidates for getting
inlined across crates. This has been happening, leading to monstrosities like
that found in #11549. I have verified that the codegen is *much* better now that
we're not inlining the failure path (the slow path).
|
|
|
|
|
|
|
|
Unique pointers and vectors currently contain a reference counting
header when containing a managed pointer.
This `{ ref_count, type_desc, prev, next }` header is not necessary and
not a sensible foundation for tracing. It adds needless complexity to
library code and is responsible for breakage in places where the branch
has been left out.
The `borrow_offset` field can now be removed from `TyDesc` along with
the associated handling in the compiler.
Closes #9510
Closes #11533
|
|
This reduces the number of moves/memcpy's we do, which makes insert
faster, especially in cases of keys with long equal prefixes (the
_low_bits tests):
Before:
bench_insert_large ... bench: 553966 ns/iter (+/- 64050)
bench_insert_large_low_bits ... bench: 1048151 ns/iter (+/- 92484)
bench_insert_small ... bench: 168840 ns/iter (+/- 22410)
bench_insert_small_low_bits ... bench: 185069 ns/iter (+/- 38332)
After:
bench_insert_large ... bench: 422132 ns/iter (+/- 35112)
bench_insert_large_low_bits ... bench: 339083 ns/iter (+/- 34421)
bench_insert_small ... bench: 134539 ns/iter (+/- 15254)
bench_insert_small_low_bits ... bench: 88775 ns/iter (+/- 5746)
|
|
|
|
This type isn't yet very useful since it only pretends cycles won't be
a problem. Anyone using it should be made aware that they're going to
leak.
|
|
|
|
Currently, we have c_void defined to be represented as an empty struct,
but LLVM expects C's void* to be represented as i8*. That means we
currently generate code in which LLVM doesn't recognize malloc() and
free() and can't apply certain optimization that would remove calls to
those functions.
|
|
|
|
|
|
|
|
|
|
These functions are of little utility outside a small subset of use cases. If people need them for their own projects then they can use their own bindings for libm (which aren't hard to make).
|
|
|
|
|
|
This fixes #11336
I guess the type sizes are correct for both OS X and iOS, but i am not certain.
In any case, i'd rather have any iOS build at all, so that we have something to improve upon.
|
|
drop_glue).
|
|
|
|
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
|
|
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
|
|
Instead of reading a byte at a time in a loop we copy the relevant bytes into
a temporary vector of size eight. We can then read the value from the temporary
vector using a single u64 read. LLVM seems to be able to optimize this
almost scarily good.
|
|
|
|
It's easy to figure out and useful as a sanity check sometimes.
|
|
It's easy to figure out and useful as a sanity check sometimes.
|
|
We just approximate with a 2MB stack for native::start.
|
|
|
|
|
|
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
|
|
The methods contained in `std::num::{Algebraic, Trigonometric, Exponential, Hyperbolic}` have now been moved into `std::num::Real`. This is part of an ongoing effort to simplify `std::num` (see issue #10387).
`std::num::RealExt` has also been removed from the prelude because it is not a commonly used trait.
r? @alexcrichton
|
|
This trait seems to stray too far from the mandate of a standard library as implementations may vary between use cases. Third party libraries should implement their own if they need something like it.
This closes #5316.
r? @alexcrichton, @pcwalton
|
|
This is just an unnecessary trait that no one's ever going to parameterize over
and it's more useful to just define the methods directly on the types
themselves. The implementors of this type almost always don't want
inner_mut_ref() but they're forced to define it as well.
|
|
This is just an unnecessary trait that no one's ever going to parameterize over
and it's more useful to just define the methods directly on the types
themselves. The implementors of this type almost always don't want
inner_mut_ref() but they're forced to define it as well.
|
|
This trait seems to stray too far from the mandate of a standard library as implementations may vary between use cases.
|
|
The methods contained in `std::num::{Algebraic, Trigonometric, Exponential, Hyperbolic}` have now been moved into `std::num::Real`. This is part of an ongoing effort to simplify `std::num` (see issue #10387).
`std::num::RealExt` has also been removed from the prelude because it is not a commonly used trait.
|
|
Closes #11372
|
|
Turned out to be a 2-line fix, but the compiler fallout was huge.
|
|
Various documentation changes, change the 'borrowed pointer' terminology to 'reference', fix a problem with 'make dist' on windows.
|
|
|
|
|
|
|
|
|
|
Fallout from the previous commits
|
