Closes #16914

Now that there are build bots with a stable enough LLDB version on OSX we can finally let the tests run on every PR!
😹 

Fix #16563

 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.

Adjust orphan rules to consider all input types, not just self type.

Fixes #18222.

r? @pcwalton 

debuginfo: Let LLDB tests run in parallel again since our min-supported version has no problems with that.

Hello! I noticed spans are wrong for the PatIdents of self args. (I use spans a lot in racer)

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

Fixes #18222.

auto merge of #18121 : nikomatsakis/rust/method-call-use-trait-matching-infrastructure-2, r=pcwalton

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.

This is about 20x faster on my machine.

are mostly new tests though I also revamped (and renamed) some of the existing tests.

some reason.

The new method lookup mechanism typechecks calls against the method type declared in the trait, not in the impl. In some cases that results in tighter rules, and in some cases looser. Correct for that.

as far as I can tell.

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.

Fix #16563

over anything that is foldable, not just fn signatures.

Also:
1. stop eagerly coercing from `[T, ..n]` to `[T]` only do so if requested.
2. permit error to be interact more freely.

Fixes #17178.

have to take the transformed self type into account, and allow for coercion between
the receiver and the actual type declared on the impl.

🐳 

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.