Let's try if not running LLDB tests in parallel solves the sporadic deadlocks we've seen since enabling the LLDB test suite. Running the tests in parallel has lead to unstable behaviour in the past (with LLDB versions below 310.x.x). Maybe our new minimum LLDB version isn't quite up to it either.
cc @alexcrichton
The real size is also more useful than just a boolean, and the caller
can easily determine if the operation failed from the real size. In most
cases, the caller is only going to be growing the allocation so a branch
can be avoided.
[breaking-change]
The C standard library functions should be used directly. The quirky
NULL / zero-size allocation workaround is no longer necessary and was
adding an extra branch to the allocator code path in a build without
jemalloc. This is a small step towards liballoc being compatible with
handling OOM errors instead of aborting (#18292).
[breaking-change]
With MIN_ALIGN as a static, other crates don't have access to its value
at compile time, because it is an extern global. That means that the
checks against it can't be optimized out, which is rather unfortunate.
So let's make it a constant instead.
Explain the primary disadvantage of garbage collection is runtime
overhead and unpredictable pauses. Elucidate where the name "race
condition" comes from. Emphasize that Rust can guarantee your code is
free of race conditions and other memory errors, with no runtime
overhead.
cc @steveklabnik
Rather than doing it top-down, with a known expected type, we will now simply establish the appropriate constraints between the pattern and the expression it destructures.
Closes#8783.
Closes#10200.
Adds an `assume` intrinsic that gets translated to llvm.assume. It is
used on a boolean expression and allows the optimizer to assume that
the expression is true.
This implements #18051.
Instead of checking patterns in a top-down fashion with a known
expected type on entry, this changes makes typeck establish
appropriate constraints between a pattern and the expression
it destructures, and lets inference compute the final types
or produce good error messages if it's impossible.
This installs signal handlers to print out stack overflow messages on Linux. It also ensures the main thread has a guard page.
This will catch stack overflows in external code. It's done in preparation of switching to stack probes (#16012).
I've done some simple tests with overflowing the main thread, native threads and green threads (with and without UV) on x86-64.
This might work on ARM, MIPS and x86-32.
I've been unable to run the test suite on this because of #16305.
Closes#17075
I don't know if this is correct. The easiest way to find out is to run the following program on all targets but I can't do it myself.
```c
#include <stdint.h>
#include <stdio.h>
int main(void)
{
if (sizeof(intmax_t) != 8) {
puts("ERROR");
return 1;
}
}
```
Old vs. New vs. Vec::push_all
```
test slice ... bench: 3091942 ns/iter (+/- 54460)
test slice_new ... bench: 1800065 ns/iter (+/- 69513)
test vec ... bench: 1804805 ns/iter (+/- 75609)
```
The variable name <code>one_to_one_hundred</code> implies that it will contain a collection with the values from 1 to 100, but the collection contains the values from 0 to 99. This patch changes the ranges to produce a collection with the values from 1 to 100.
