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.
Enable parallel codegen (2 units) by default when --opt-level is 0 or 1. This
gives a minor speedup on large crates (~10%), with only a tiny slowdown (~2%)
for small ones (which usually build in under a second regardless). The current
default (no parallelization) is used when the user requests optimization
(--opt-level 2 or 3), and when the user has enabled LTO (which is incompatible
with parallel codegen).
This commit also changes the rust build system to use parallel codegen
when appropriate. This means codegen-units=4 for stage0 always, and
also for stage1 and stage2 when configured with --disable-optimize.
(Other settings use codegen-units=1 for stage1 and stage2, to get
maximum performance for release binaries.) The build system also sets
codegen-units=1 for compiletest tests (compiletest does its own
parallelization) and uses the same setting as stage2 for crate tests.
r? @aturon
Convert trait method dispatch to use new trait matching machinery.
This fixes about 90% of #17918. What remains to be done is to make inherent dispatch work with conditional dispatch as well. I plan to do this in a future patch by generalizing the "method match" code slightly to work for inherent impls as well (the basic algorithm is precisely the same).
Fixes#17178.
This is a [breaking-change] for two reasons:
1. The old code was a bit broken. I found various minor cases, particularly around operators, where the old code incorrectly matched, but an extra `*` or other change is now required. (See commit e8cef25 ("Correct case where the old version of method lookup...") for examples.)
2. The old code didn't type check calls against the method signature from the *trait* but rather the *impl*. The two can be different in subtle ways. This makes the new method dispatch both more liberal and more conservative than the original. (See commit 8308332 ("The new method lookup mechanism typechecks...") for examples.)
r? @pcwalton since he's been reviewing most of this series of changes
f? @nick29581 for commit 39df55f ("Permit DST types to unify like other types")
cc @aturon as this relates to library stabilization
Enable parallel codegen (2 units) by default when --opt-level is 0 or 1. This
gives a minor speedup on large crates (~10%), with only a tiny slowdown (~2%)
for small ones (which usually build in under a second regardless). The current
default (no parallelization) is used when the user requests optimization
(--opt-level 2 or 3), and when the user has enabled LTO (which is incompatible
with parallel codegen).
This commit also changes the rust build system to use parallel codegen
when appropriate. This means codegen-units=4 for stage0 always, and
also for stage1 and stage2 when configured with --disable-optimize.
(Other settings use codegen-units=1 for stage1 and stage2, to get
maximum performance for release binaries.) The build system also sets
codegen-units=1 for compiletest tests (compiletest does its own
parallelization) and uses the same setting as stage2 for crate tests.
of tracking individual candidates per impl, we just track one
candidate for the extension trait itself, and let the trait resolution
handle walking the individual impls and so forth. Also change the
interface to report back a richer notion of error.
Finishes the job of #17286.
Now the stability lint will successfully detect patterns such as:
```
first_macro!(second_macro!(deprecated_function()));
```
```
macro_rules! foo (
($e: expr) => (bar!($e))
)
foo!(deprected_function());
```
and
```
println!("{}", deprecated_function());
```
even with more levels of nesting, such as
```
println!("{}", foo!(bar!(deprecated_function())));
```
This was run into while attempting to integrate rust with bitbake's build system. I expect it's caused by some other environment variables being set to gcc but didn't track down the exact cause myself.
