Use forward traversal for unconditional recursion lint
While reviewing #70822, I noted that #54444 could be solved without requiring the predecessor graph and without allocating a `Vec<Span>` for every basic block. The unconditional recursion lint is not a performance bottleneck however, so I approved #70822 as it was.
Nevertheless, I wanted to try implementing my idea using `TriColorDepthFirstSearch`, which is a DFS that can differentiate between [forward/tree edges and backward ones](https://en.wikipedia.org/wiki/Depth-first_search#Output_of_a_depth-first_search). I found this approach more straightforward than the existing one, so I'm opening this PR to see if it is desirable.
The pass is now just a DFS across the control-flow graph. We ignore false edges and false unwinds, as well as the successors of recursive calls, just like existing pass does. If we see a back-edge (loop) or a terminator that would cause us to yield control-flow back to the caller (`Return`, `Resume`, etc.), we know that the function does not unconditionally recurse.
r? @jonas-schievink
Use `PredicateObligation`s instead of `Predicate`s
Keep more information about trait binding failures. Use more specific spans by pointing at bindings that introduce obligations.
Subset of #69709.
r? @eddyb
Stop explicitly depending on python 2
This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually, by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available).
The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such, though only on one builder. This is intended as a temporary, though likely long-lived, measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future, depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time.
Closes#65063 (as far as I can tell; please file explicit and separate issues or PRs if not).
The `_` binding form is special, in that it encodes a "no-op": nothing is
actually bound, and thus nothing is moved or borrowed in this scenario. Usually
we do the "right" thing in all such cases. The exceptions are explicitly pointed
out in this test case, so that we keep track of whether they are eventually
fixed.
Rollup of 8 pull requests
Successful merges:
- #70784 (Consider methods on fundamental `impl` when method is not found on numeric type)
- #70843 (Remove the Ord bound that was plaguing drain_filter)
- #70913 (Replace "rc"/"arc" lang items with Rc/Arc diagnostic items.)
- #70932 (De-abuse TyKind::Error in pattern type checking)
- #70952 (Clean up E0511 explanation)
- #70964 (rustc_session CLI lint parsing: mark a temporary hack as such)
- #70969 (Fix JSON file_name documentation for macros.)
- #70975 (Fix internal doc comment nits.)
Failed merges:
r? @ghost
Fix JSON file_name documentation for macros.
JSON `file_name` paths were changed in #66364 for macros to point to actual source files instead of using `<MACRONAME macros>`.
Closes#70396
rustc_session CLI lint parsing: mark a temporary hack as such
This code was added in https://github.com/rust-lang/rust/pull/70918, but it should not be necessary any more once `forbid` works as expected for in-code attributes.
Cc @tobithiel @davidtwco
De-abuse TyKind::Error in pattern type checking
r? @eddyb
cc https://github.com/rust-lang/rust/issues/70866
In particular, I would appreciate extra scrutiny over the soundness of these changes.
Also, this will go a bit slowly because I'm going to use my other PR (#70551) to check if I missed anything.
Replace "rc"/"arc" lang items with Rc/Arc diagnostic items.
`Rc`/`Arc` should have no special semantics, so it seems appropriate for them to not be lang items.
r? @matthewjasper
Remove the Ord bound that was plaguing drain_filter
Now that #70795 made it superfluous. Also removes superfluous lifetime specifiers (at least I think they are).
Enable rust-lld on dist-x86_64-musl
Add rust-lld to rustup llvm-tools-preview on nightly for musl
I am using a musl distro on my workstation, with `RUSTFLAGS="-C target-feature=-crt-static"` this works fine. I know that `x86_64-unknown-linux-musl` was originally only meant as a target and not as a host. But most problems have been fixed, and I have fewer problems with `unknown` (rustup) than when I am using `x86_64-alpine-linux-musl` (rust installed by the distro). The only thing I am missing is rust-lld in llvm-tools-preview on nightly.
I needed rust-lld for a wasm tutorial. I built rust-lld and tested it with that tutorial, and it worked well. I asked [here](https://users.rust-lang.org/t/enable-rust-lld-on-x86-64-unknown-linux-musl/39851) where to request to enable lld and ended up doing this PR.
I compared llvm-tools-preview `nightly-x86_64-unknown-linux-musl` and `nightly-x86_64-unknown-linux-gnu`: only rust-lld is missing in musl.
I tested the change using:
```bash
./src/ci/docker/run.sh dist-x86_64-musl
```
And I checked that the resulting rust-lld binary runs.
Add utility to find locals that don't use `StorageLive` annotations and use it for `MaybeStorageLive`
Addresses https://github.com/rust-lang/rust/pull/70004#issuecomment-599271717 (cc @RalfJung).
The only dataflow analysis that is incorrect in this case is `MaybeStorageLive`. `transform/generator.rs` implemented custom handling for this class of locals, but other consumers of this analysis (there's one in [clippy](513b46793e/clippy_lints/src/redundant_clone.rs (L402))) would be incorrect.
r? @tmandry
librustc_hir: return LocalDefId instead of DefId in local_def_id
Its a first try to remove a few calls to `expect_local` and use `LocalDefId` instead of `DefId` where possible for #70853
This adds some calls to `.to_def_id()` to get a `DefId` back when needed. I don't know if I should push `LocalDefId` even further and change, for example, `Res::Def` to accept a `LocalDefId` instead of a `DefId` as second argument.
cc @ecstatic-morse
