Remove armv5te target from dist-various-1
Reverts https://github.com/rust-lang/rust/pull/46498
I must have made some mistake when I tested that commit and thought armv5te target worked. but testing it now the produced binaries segfaults (https://github.com/rust-lang/rust/pull/46498#issuecomment-350599233).
I tried using crosstool-ng and buildroot toolchain (for armv5te) but the produced binaries also segfaults. Maybe there is a issue with the target, but I cannot investigate it any further.
I think the best for now is not to distribute the armv5te target.
I'm sorry for what happened.
Mark ascii methods on primitive types stable in 1.23.0 not 1.21.0.
The ascii_methods_on_intrinsics feature stabilization
didn't land in time for 1.21.0. Update the annotation
so the documentation is correct about when these
methods became available.
move `resolve_lifetimes` into a proper query
Now that we made `resolve_lifetimes` into a query, elision errors no
longer abort compilation, which affects some tests.
Also, remove `dep_graph_crosscontaminate_tables` -- there is no a path in
the dep-graph, though red-green handles it. The same scenario
is (correctly) tested by issue-42602.rs in any case.
r? @michaelwoerister
Reverts https://github.com/rust-lang/rust/pull/46498
I must have made some mistake when I tested that commit and thought
armv5te target worked. but testing it now the produced binaries
segfaults
(https://github.com/rust-lang/rust/pull/46498#issuecomment-350599233).
I tried using crosstool-ng and buildroot toolchain (for armv5te) but
the produced binaries also segfaults. Maybe there is a issue with the
target, but I cannot investigate it any further.
I think the best for now is not to distribute the armv5te target.
I'm sorry for what happened.
Now that we made `resolve_lifetimes` into a query, elision errors no
longer abort compilation, which affects some tests.
Also, remove `dep_graph_crosscontaminate_tables` -- there is no a path in
the dep-graph, though red-green handles it. The same scenario
is (correctly) tested by issue-42602.rs in any case.
To avoid confusion in cases where the code is
```rust
fn foo() {}
/ foo(
| bar()
| ^^^ current diagnostics point here for arg count mismatch
| );
|_^ new diagnostic span points here
```
as this leads to confusion making people think that the diagnostic is
talking about `bar`'s arg count, not `foo`'s.
Point at `fn`s definition on arg mismatch, just like we do for closures.
If the gen/kill bits are set there, the effects of `start_block_effects`
will not be seen when using `FlowAtLocation` etc. to go over the MIR.
EverInitializedLvals is the only pass that got this wrong, but this
fixes the footgun for everyone.
kennytm
