Rollup of 6 pull requests
Successful merges:
- #115770 (Match on elem first while building move paths)
- #115999 (Capture scrutinee of if let guards correctly)
- #116056 (Make unsized casts illegal)
- #116061 (Remove TaKO8Ki from review rotation)
- #116062 (Change `start` to `#[start]` in some diagnosis)
- #116067 (Open the FileEncoder file for reading and writing)
r? `@ghost`
`@rustbot` modify labels: rollup
Open the FileEncoder file for reading and writing
Maybe I just don't know `File` well enough, but the previous comment didn't make it clear enough to me that we can't use `File::create`. This one does.
Fixes https://github.com/rust-lang/rust/issues/116055
r? `@WaffleLapkin`
Remove TaKO8Ki from review rotation
`@TaKO8Ki` you haven't been actively reviewing pull requests lately, so I'm removing you from the rotation. Thank you for all the PRs you have reviewed when you were more actively, it was very helpful! Feel free to add yourself back when you have more time 💜
r? `@wesleywiser` `@davidtwco`
Match on elem first while building move paths
While working on https://github.com/rust-lang/rust/pull/115025 `@lcnr` and I observed "move_paths_for" function matched on the `Ty` instead of `Projection` which seems flawed as it's the `Projection`s that cause the problem not the type.
r? `@lcnr`
[breaking change] Validate crate name in `--extern` [MCP 650]
Reject non-ASCII-identifier crate names passed to the CLI option `--extern` (`rustc`, `rustdoc`).
Implements [MCP 650](https://github.com/rust-lang/compiler-team/issues/650) (except that we only allow ASCII identifiers not arbitrary Rust identifiers).
Fixes#113035.
[As mentioned on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Disallow.20non-identifier-valid.20--extern.20cr.E2.80.A6.20compiler-team.23650/near/376826988), doing a crater run probably doesn't make sense since it wouldn't yield anything. Most users don't interact with `rustc` directly but only ever through Cargo which always passes a valid crate name to `--extern` when it invokes `rustc` and `rustdoc`. In any case, the user wouldn't be able to use such a crate name in the source code anyway.
Note that I'm not using [`rustc_session::output::validate_crate_name`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/output/fn.validate_crate_name.html) (used for `--crate-name` and `#![crate_name]`) since the latter doesn't reject non-ASCII crate names and ones that start with a digit.
As an aside, I've also thought about getting rid of `validate_crate_name` entirely in a separate PR (with another MCP) in favor of `is_ascii_ident` to reject more weird `--crate-name`s, `#![crate_name]`s and file names but I think that would lead to a lot of actual breakage, namely because of file names starting with a digit. In `tests/ui` 9 tests would be impacted for example.
CC `@estebank`
r? `@est31`
adjust how closure/generator types are printed
I saw `&[closure@$DIR/issue-20862.rs:2:5]` and I thought it is a slice type, because that's usually what `&[_]` is... it took me a while to realize that this is just a confusing printer and actually there's no slice. Let's use something that cannot be mistaken for a regular type.
Allow `-Z treat-err-as-bug=0`
Makes `-Z treat-err-as-bug=0` behave as if the option wasn't present instead of asking the value to be ⩾ 1. This enables a quick on/off of the option, as you only need to change one character instead of removing the whole `-Z`.
Also update some text, e.g.
```bash
$ rustc -Z help | grep treat-err-as-bug
-Z treat-err-as-bug=val -- treat error number `val` that occurs as bug
```
where the value could be interpreted as an error code instead of an ordinal.
give FutureIncompatibilityReason variants more explicit names
Also make the `reason` field mandatory when declaring a lint, to make sure this is a deliberate decision.
tests/ui: Split large_moves.rs and move to lint/large_assignments
To make failing tests easier to debug with `--emit=mir`, etc.
Don't bother with `revisions: attribute option` for both tests though. Seems sufficient to just have that on one of the tests.
`git show -M --find-renames=40%` makes the diff easier to review. Or note that before this change we had one test with 4 errors, now we have 2 tests with 2 errors each.
r? `@oli-obk`
Part of https://github.com/rust-lang/rust/issues/83518
Command: also print removed env vars
There is no real shell syntax for unsetting an env var so easily, so we have to make one up. But we already do that for showing the 'program' name so I hope that's okay here, too. No strong opinion on what that should look like, I went with `unset(VAR_NAME)` for now.
Move `DepKind` to `rustc_query_system` and define it as `u16`
This moves the `DepKind` type to `rustc_query_system` where it's defined with an inner `u16` field. This decouples it from `rustc_middle` and is a step towards letting other crates define dep kinds. It also allows some type parameters to be removed. The `DepKind` trait is replaced with a `Deps` trait. That's used when some operations or information about dep kinds which is unavailable in `rustc_query_system` are still needed.
r? `@cjgillot`
rustc_hir_analysis: add a helper to check function the signature mismatches
This function is now used to check `#[panic_handler]`, `start` lang item, `main`, `#[start]` and intrinsic functions.
The diagnosis produced are now closer to the ones produced by trait/impl method signature mismatch.
This is the first time I do anything with rustc_hir_analysis/rustc_hir_typeck, so comments and suggestions about things I did wrong or that could be improved will be appreciated.
Suggest desugaring to return-position `impl Future` when an `async fn` in trait fails an auto trait bound
First commit allows us to store the span of the `async` keyword in HIR.
Second commit implements a suggestion to desugar an `async fn` to a return-position `impl Future` in trait to slightly improve the `Send` situation being discussed in #115822.
This suggestion is only made when `#![feature(return_type_notation)]` is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.
coverage: Don't bother renumbering expressions on the Rust side
The LLVM API that we use to encode coverage mappings already has its own code for removing unused coverage expressions and renumbering the rest.
This lets us get rid of our own complex renumbering code, making it easier to change our coverage code in other ways.
---
Now that we have tests for coverage mappings (#114843), I've been able to verify that this PR doesn't make the coverage mappings worse, thanks to an explicit simplification step.
