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.
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.
304c8b1edabcd 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.
