This PR introduce a repetition in the source files `crates/ide_completion/render/pattern.rs` and `crates/ide_completion/render/struct_literal.rs` that may be fix in another PR.
`HirFileId::expansion_info` can return `None` for builtin macros or if there's an error in the macro call or definition, so add a `HirFileId::is_macro` method that checks the right thing.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
- fix: It doesn't try to overwrite parts of selected comments any longer
- fix: It doesn't wrap tail expressions and return types in a result or option unnecessarily
- feat?: It now adds a `const` modifier to the created function if extract somethings from a const context
bors[bot] [Tue, 3 Aug 2021 12:13:05 +0000 (12:13 +0000)]
Merge #9771
9771: Give better error message when the rust-analyzer binary path was set in the user's config but the binary is invalid r=matklad a=rylev
`@yoshuawuyts` and I ran into an issue where my rust-analyzer binary path was set in my extension config (which I didn't realize), but the path set in the config was invalid (it simply wasn't on my path). Having an error message that hinted that the binary's path was explicitly set in the config would have considerably shortened the debug time.
bors[bot] [Mon, 2 Aug 2021 18:43:02 +0000 (18:43 +0000)]
Merge #9764
9764: fix: Don't use the module as the candidate node in fuzzy path flyimport r=Veykril a=Veykril
The problem was that the candidate node is whats being used for the scope, so using an inline module will yield the surrounding scope of the module instead of the scope of the module itself.
Also seems to fix the problem in this comment https://github.com/rust-analyzer/rust-analyzer/issues/9760#issuecomment-891125674, though I could not recreate that in a test for some reason.
bors[bot] [Mon, 2 Aug 2021 15:44:43 +0000 (15:44 +0000)]
Merge #9761
9761: feat: Show coerced types on type hover r=Veykril a=Veykril
This applies to both the ranged hover request as well as the normal hover type fallback.
![image](https://user-images.githubusercontent.com/3757771/127883884-2935b624-a3e5-4f35-861a-7d6d3266d187.png)
![image](https://user-images.githubusercontent.com/3757771/127883951-4ff96b6b-7576-4886-887b-1198c1121841.png)
We unfortunately have to leave out syntax highlighting here as otherwise the `Type` and `Coerced` words in the hover will get colored.
Note that this does not show all the coercions yet(and almost no pattern coercions) as not all coercion adjustments are implemented yet.
bors[bot] [Mon, 2 Aug 2021 14:12:37 +0000 (14:12 +0000)]
Merge #9751
9751: Make `LoadCargoConfig`, `fn load_workspace_at` & `fn load_workspace` public again r=matklad a=regexident
This [commit](https://github.com/rust-analyzer/rust-analyzer/commit/b24f816c0d8aaa37fbc0b33f90dd67afbf28adaa) which restricted the visibility of `LoadCargoConfig`, `fn load_workspace_at` & `fn load_workspace` unfortunately effectively rendered every crate/tool that uses rust-analyzer as a library dead in the water.
On of such tools is [cargo-modules](https://github.com/regexident/cargo-modules), a tool for generating tree/graph visualizations of one's Rust project and is powered by rust-analyzer as a library.
For more context see the PRs that introduced those types/functions and made them `pub`:
bors[bot] [Mon, 2 Aug 2021 13:14:22 +0000 (13:14 +0000)]
Merge #9752
9752: feature: Declare proc-macro dependent crates in `rust-project.json` r=matklad a=tobywf
This adds the `is_proc_macro` flag in `rust-project.json`. By default, this is `false` and not required, so existing projects won't break/have the same behavior as before this change. If the flag is true, a dependency to the `proc_macro` sysroot crate is added (if it exists), so that rust-analyzer can resolve those imports.
This fixes #9726 .
I've also added some tests in the second commit. The first is a smoke test for a basic, minimal `rust-project.json` file. The second is a more targeted test for the flag. Both tests depend on the fake sysroot (a bunch of directories in the correct layout with empty `lib.rs` files), and also on `env!("CARGO_MANIFEST_DIR")` being an absolute path. I'm not sure if the later assumption is valid on all platforms. I wanted to at least try and add tests, but I'm happy to rework them or remove them if you don't think that's the way to go.
(You can license/relicense my contribution in any way you wish without contacting me.)
bors[bot] [Sun, 1 Aug 2021 14:40:44 +0000 (14:40 +0000)]
Merge #9750
9750: Link “DST” to its definition r=lnicola a=gthb
Being new to Rust I wasn't familiar with this acronym and found it hard to guess (the context of syntax trees biased me to reading it as a D-something Syntax Tree and trying to guess what the D was), hard to google (in retrospect googling "rust dst" does the job, but I thought it was an abstract structure thing, not Rust-specific), and hard to Github-search, because `dst` is commonly short for “destination” in code.
Alternatively `<abbr title="dynamically sized type">DST</abbr>` would be about as helpful.
Being new to Rust I wasn't familiar with this acronym and found it hard to guess (the context of syntax trees biased me to reading it as a D-something Syntax Tree and trying to guess what the D was), hard to google (in retrospect googling "rust dst" does the job, but I thought it was an abstract structure thing, not Rust-specific), and hard to Github-search, because `dst` is commonly short for “destination” in code.
Alternatively `<abbr title="dynamically sized type">DST</abbr>` would be about as helpful.
bors[bot] [Sun, 1 Aug 2021 10:11:07 +0000 (10:11 +0000)]
Merge #9749
9749: Exclude `rust-analyzer.server.path` from VS Code's sync feature r=lnicola a=brainplot
By changing the scope of this configuration to `machine-overridible`, this setting becomes fully local for the VS Code instance the user is running.
Having this setting excluded from syncing should help avoid inconveniences for users who have VS Code installed on two different operating systems, where the paths to the language server binary would very likely mismatch.
Exclude `rust-analyzer.server.path` from VS Code's sync feature
By changing the scope of this configuration to `machine-overridible`,
this setting becomes fully local for the VS Code instance the user is
running.
Having this setting excluded from syncing should help avoid
inconveniences for users who have VS Code installed on two different
operating systems, where the paths to the language server binary would
very likely mismatch.
9744: fix: Annotate type hints for pattern name ranges instead of the pattern itself r=Veykril a=Veykril
The current type hints do not go well with `bindings_after_at` which is likely to land with 1.56(https://github.com/rust-lang/rust/pull/85305 🎉very excited for this), hence annotate the names of ident patterns instead of the entire pattern.
This changes where the typehints go for ident patterns that use @ bindings, some example comparisons:
Some features of rust-analyzer requires support for custom commands on
the client side. Specifically, hover & code lens need this.
Stock LSP doesn't have a way for the server to know which client-side
commands are available. For that reason, we historically were just
sending the commands, not worrying whether the client supports then or
not.
That's not really great though, so in this PR we add infrastructure for
the client to explicitly opt-into custom commands, via `extensions`
field of the ClientCapabilities.
To preserve backwards compatability, if the client doesn't set the
field, we assume that it does support all custom commands. In the
future, we'll start treating that case as if the client doesn't support
commands.
So, if you maintain a rust-analyzer client and implement
`rust-analyzer/runSingle` and such, please also advertise this via a
capability.
Adds the counterpart for the `replace_string_with_char` assist and fixes the assist not escaping the `'` in the string `"'"` when transforming that to a char.
bors r+