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.
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.
We issue just one message for an erroneous glob private variant reëxport
(using the Session's one-time-diagnostics capability), but individual
(non-glob) such erroneous reëxports still get their own messages. The
suggestion to make the enum public is also one-time.
The enum variant reëxport error didn't have an associated error code
(and remedying this here is deemed out of the scope of this commit), so
we resort to the expediency of using 0 as the `DiagnosticMessageId`
value.
Adding Debug to NameResolution was helpful in development.
This resolves#46209.
304c8b1eda made the Session's one-time-diagnostics set take a
special-purpose `DiagnosticMessageId` enum rather than a LintID so that
it could support more than just lints, but the `diag_span_note_once` and
`diag_note_once` methods continued to take references to lints: for API
consistency, we now make these methods take a `DiagnosticMessageId`
while we add support for one-time span-suggestions.
