internal: port anymap
## Description
- The anymap crate has been ported. During this process, unnecessary features for rust-analyzer have been removed.
- From the tests that were checking the existing licenses, the anymap license (`BlueOak-1.0.0 OR MIT OR Apache-2.0`) has been removed.
## Requests
- While porting the code this time, I have tried to respect the original author's intentions and have kept the comments/codes as much as possible. Please don't hesitate to tell me if you think the comments/codes also need to be appropriately modified.
- If there are any necessary changes regarding the licensing or anything else, please let me know so I can fix them.
## Issue
https://github.com/rust-lang/rust-analyzer/issues/15500
feat: implement tuple return type to tuple struct assist
This PR implements the `convert_tuple_return_type_to_struct` assist, for converting the return type of a function or method from a tuple to a tuple struct. Additionally, it moves the `to_camel_case` and `char_has_case` functions from `case_conv` to `stdx` so that they can be used similar to `to_lower_snake_case`.
[tuple_return_type_to_tuple_struct.webm](https://github.com/rust-lang/rust-analyzer/assets/52933714/2803ff58-fde3-4144-9495-7c7c7e139075)
Currently, the assist puts the struct definition above the function, or above the nearest `impl` or `trait` if applicable and only rewrites literal tuples that are returned in the body of the function. Additionally, it only attempts to rewrite simple tuple pattern usages with the corresponding tuple struct pattern but does so across files and modules.
I think that this is sufficient for the majority of use cases but I could be wrong. One thing I'm still not sure how to approach is handling `Self` and generics/lifetimes in the tuple type to be extracted. I was thinking of either manually figuring out what lifetimes and generics are in scope and using them (sort of similar to the `generate_function` assist) or maybe using `ctx.sema.resolve_type` and `generic_params` on `hir::Type` but this seems to not deal with lifetimes.
Closes#14293
Add config option to use `rust-analyzer` specific target dir
Adds a Rust Analyzer configuration option to set a custom target directory for builds. This is a workaround for Rust Analyzer blocking debug builds while running `cargo check`. This change should close#6007.
This is my first time contributing to this project, so any feedback regarding best practices that I'm not aware of are greatly appreciated! Thanks to all the maintainers for their hard work on this project and reviewing contributions.
Add dedicated field for `target_dir` in the configurations for Cargo
and Flycheck. Also change the directory to be a `PathBuf` as opposed to
a `String` to be more appropriate to the operating system.
Adds a Rust Analyzer configuration option to set a custom
target directory for builds. This is a workaround for Rust Analyzer
blocking debug builds while running `cargo check`. This change
should close#6007
internal: fix automatic rustc/rustdoc lint generation
Missed in #15680: the output of `-Whelp` changed since the last run so it generated some bad rustdoc lints entries.
Also preemptively fix a `-Whelp` breakage that might get merged in rust-lang/rust#116412
fix: ensure `rustfmt` runs when configured with `./`
(Hopefully) resolves https://github.com/rust-lang/rust-analyzer/issues/15595. This change kinda approaches canonicalization—which I am not a fan of—but only in service of making `./`-configured commands run correctly.
Longer-term, I feel like this code should be removed once `rustfmt` supports recursive searches of configuration files or interpolation of values like `${workspace_folder}` lands in rust-analyzer.
## Testing
I cloned `rustc`, setup rust-analyzer as suggested in the [`rustc` dev guide](https://rustc-dev-guide.rust-lang.org/building/suggested.html#configuring-rust-analyzer-for-rustc), saved and formatted files in `src/tools/miri` and `compiler`, and saw `rustfmt` (seemingly) correctly.
feat: add backtick to surrounding and auto-closing pairs
Makes backticks always complete as a pair and also surround the current selection, similar to double quotes. This is useful primarily in the context of markdown doc comments, but is applied globally for simplicity.
Closes https://github.com/rust-lang/rust-analyzer/issues/11381
vscode: Fix line and col regexp for `rustc` problem matcher
When building the Rust compiler with `./x check` from within VS Code, the current `rustc` problem matcher thinks that the output from that command that looks like this:
Build completed successfully in 0:00:26
is about a problem in a file named `0` on line 00, col 26. This wouldn't be so bad if it wasn't for that VS Code tends to get stuck on this problem because of problems with opening the file '0'.
The rust compiler will never output problems with a line or a column that starts with 0, so change the regexp to require lines and cols to begin with `[1-9]` to fix this problem.
fix: allow more kinds of if let patterns in guarded return assist
Removes the checks that require the pattern to be a tuple struct with exactly 1 field that is unqualified and has an identifier pattern in it. I'm not sure if there should be more checks in place but they seem unnecessary now?
Closes#15695
When building the Rust compiler with `./x check` from within VS Code,
the current `rustc` problem matcher thinks that the output from that
command that looks like this:
Build completed successfully in 0:00:26
is about a problem in a file named `0` on line 00, col 26. This wouldn't
be so bad if it wasn't for that VS Code tends to get stuck on this
problem because of problems with opening the file '0'.
The rust compiler will never output problems with a line or a column
that starts with 0, so change the regexp to require lines and cols to
begin with [1-9] to fix this problem.
