Amend style guide section for formatting where clauses in type aliases
This PR has two parts:
1. Amend wording about breaking before or after the `=`, which is a style guide bugfix to align it with current rustfmt behavior.
2. Explain how to format trailing (#89122) where clauses, which are preferred in both GATs (#90076) and type aliases (#114662).
r? `@joshtriplett`
fix: panic with wrapping/unwrapping result return type assists
With the `wrap_return_type_in_result` assist, the following code results in a panic (note the lack of a semicolon):
```rust
fn foo(num: i32) -> $0i32 {
return num
}
=>
thread 'handlers::wrap_return_type_in_result::tests::wrap_return_in_tail_position' panicked at crates/syntax/src/ted.rs:137:41:
called `Option::unwrap()` on a `None` value
```
I think this is because it first walks the body expression to change any `return` expressions and then walks all tail expressions, resulting in the `return num` being changed twice since it is both a `return` and in tail position. This can also happen when a `match` is in tail position and `return` is used in a branch for example. Not really sure how big of an issue this is in practice though since this seems to be the only case that is impacted and can be reduced to just `num` instead of `return num`.
This also occurs with the `unwrap_result_return_type` assist but panics with the following instead:
```
thread 'handlers::unwrap_result_return_type::tests::wrap_return_in_tail_position' panicked at /rustc/3223b0b5e8dadda3f76c3fd1a8d6c5addc09599e/library/alloc/src/string.rs:1766:29:
assertion failed: self.is_char_boundary(n)
```
minor: hover_simple refactor
A minor refactor of `hover_simple` opportunity I noticed while skimming through the code.
- `if let`s -> `match`
- `iter::once(x).cycle` -> `iter::repeat`
- `classify_token` -> `classify_node`
Raise minimum supported Apple OS versions
This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (https://github.com/rust-lang/compiler-team/issues/556).
As of this PR, rustc and the stdlib now support these versions as the baseline:
- macOS: 10.12 Sierra
- iOS: 10
- tvOS: 10
- watchOS: 5 (Unchanged)
In addition to everything this breaks indirectly, these changes also erase the `armv7-apple-ios` target (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing.
[Per comment](https://github.com/rust-lang/compiler-team/issues/556#issuecomment-1297175073), this requires a FCP to merge. cc `@wesleywiser.`
[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`
extend check.overrideCommand and buildScripts.overrideCommand docs
Extend check.overrideCommand and buildScripts.overrideCommand docs regarding invocation strategy and location.
However something still seems a bit odd -- the docs for `invocationStrategy`/`invocationLocation` talk about "workspaces", but the setting that controls which workspaces are considered is called `linkedProjects`. Is a project the same as a workspace here or is there some subtle difference?
minor : Deunwrap convert_comment_block and desugar_doc_comment
Closes subtask 13 of #15398 . I still don't know a more idiomatic way for the for loops I added, any suggestion would make me happy.
Although it doesn't panic now, further changes to how we recover from incomplete syntax
may cause this assist to panic. To mitigate this a test case has been added.
Fix autoimport does nothing when importing trait that is as _ imports
Potentially fixes#15128
There are two cases of imports:
1. With simple path
2. With use tree list (or say complex path).
On deeper inspection, the [`recursive_merge`](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L87)) function (called by [`try_merge_trees_mut`)](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L69)) is meaningful only in the case of complex path (i.e when the UseTree contains a UseTreeList).
The [`recursive_merge`](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L87)) function has [match with `Ok` arm](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L106)), that is only executed when both LHS and RHS has `PathSegment` with same `NameRef`. The removal of underscore is implemented in this arm in the case of complex path.
For simple paths, the underscore is removed by checking if both LHS and RHS are simple paths and if their `Path` is same (the check is done [here](994df3d6a3/crates/ide-db/src/imports/merge_imports.rs (L74))) and remove the underscore if one is found (I made an assumption here that RHS will always be what rust-analyzer suggests to import, because at this point I'm not sure how to remove underscore with help of `ted::replace`).
feat: Bool to enum assist
This adds the `bool_to_enum` assist, which converts the type of boolean local variables, fields, constants and statics to a new `enum` type, making it easier to distinguish the meaning of `true` and `false` by renaming the variants.
Closes#14779
Fix inlining closures from local variables and functions
Previously, closures were not properly wrapped in parentheses for the `inline_local_variable` and `inline_call` assists, leading to the usages being incorrectly called:
```rust
fn main() {
let $0f = || 2;
let _ = f();
}
```
Now produces:
```rust
fn main() {
let _ = (|| 2)();
}
```
Instead of:
```rust
fn main() {
let _ = || 2();
}
```
Closes#15639
