Declaration names sounds like a name of declaration -- something you
can use for analysis. It empathically isn't, and is just a label
displayed in various UI. It's important not to confuse the two, least
we accidentally mix semantics with UI (I believe, there's already a
case of this in the FamousDefs at least).
The proper fix I think is:
* move rust-lang/rust library crates to a separate workspace
* when packaging rust-src component, vendor sources of external deps
This errro specifically:
Updating crates.io index
error: failed to select a version for the requirement `ra_ap_stdx = "^0.0.0"`
candidate versions found which didn't match: 0.0.20
location searched: /home/runner/work/rust-analyzer/rust-analyzer/crates/stdx
required by package `ra_ap_completion v0.0.20 (/home/runner/work/rust-analyzer/rust-analyzer/crates/completion)`
error: unable to update Cargo.lock
Error: Process completed with exit code 1.
6246: Follow symlinks when walking project trees r=lnicola a=dfoxfranke
Fixes#3691.
~~WIP pending further testing~~:
- [X] Verify that symlinked files get indexed.
- [x] Verify that files in symlinked directories get indexed.
- [x] Verify that inotify events are properly received and handled when the target of a symlink resides outside the project tree.
Co-authored-by: Daniel Fox Franke <dfoxfranke@gmail.com>
6220: implement binary operator overloading type inference r=flodiebold a=ruabmbua
Extend type inference of *binary operator expression*, by adding support for operator overloads.
Before this merge request, the type inference of binary expressions could only resolve operations done on built-in primitive types. This merge requests adds a code path, which is executed in case the built-in inference could not get any results. It resolves the proper operator overload trait in *core::ops* via lang items, and then resolves the associated *Output* type.
```rust
struct V2([f32; 2]);
#[lang = "add"]
pub trait Add<Rhs = Self> {
/// The resulting type after applying the `+` operator.
type Output;
/// Performs the `+` operation.
#[must_use]
fn add(self, rhs: Rhs) -> Self::Output;
}
impl Add<V2> for V2 {
type Output = V2;
fn add(self, rhs: V2) -> V2 {
let x = self.0[0] + rhs.0[0];
let y = self.0[1] + rhs.0[1];
V2([x, y])
}
}
fn test() {
let va = V2([0.0, 1.0]);
let vb = V2([0.0, 1.0]);
let r = va + vb; // This infers to V2 now
}
```
There is a problem with operator overloads, which do not explicitly set the *Rhs* type parameter in the respective impl block.
**Example:**
```rust
impl Add for V2 {
type Output = V2;
fn add(self, rhs: V2) -> V2 {
let x = self.0[0] + rhs.0[0];
let y = self.0[1] + rhs.0[1];
V2([x, y])
}
}
```
In this case, the trait solver does not realize, that the *Rhs* type parameter is actually self in the context of the impl block. This stops type inference in its tracks, and it can not resolve the associated *Output* type.
I guess we can still merge this back, because it increases the amount of resolved types, and does not regress anything (in the tests).
Somewhat blocked by https://github.com/rust-analyzer/rust-analyzer/issues/5685
Resolves https://github.com/rust-analyzer/rust-analyzer/issues/5544
Co-authored-by: Roland Ruckerbauer <roland.rucky@gmail.com>
6234: Fix hover over field pattern shorthand r=matklad a=Vlad-Shcherbina
Instead of the information about the field, it now shows the information
about the local.
Fixes#6146
Co-authored-by: Vlad Shcherbina <vlad.shcherbina@gmail.com>
6231: Factor macro_rules and format-string highlighting out into submodules r=Veykril a=Veykril
This moves `format`-like macro string highlighting and macro_rules highlight skipping out of the main module.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6207: Extract ImportAssets out of auto_import r=matklad a=Veykril
See https://github.com/rust-analyzer/rust-analyzer/pull/6172#issuecomment-707182140
I couldn't fully pull out `AssistContext` as `find_node_at_offset_with_descend`: 81fa00c5b5/crates/assists/src/assist_context.rs (L90-L92) requires the `SourceFile` which is private in it and I don't think making it public just for this is the right call?
6224: ⬆️ salsa r=matklad a=matklad
bors r+
🤖
6226: Add reminder to update lsp-extensions.md r=matklad a=matklad
bors r+
🤖
6227: Reduce bors timeout r=matklad a=matklad
bors r+
🤖
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
6130: Items case quick fix (snake_case / UPPER_SNAKE_CASE / CamelCase) r=matklad a=popzxc
Resolves#4598.
After a third try, it finally works. Boy, it appeared tougher than it seemed.
Initially I thought like "Ha, `rustc` already tells us where idents are named incorrectly. It shouldn't be that hard, should it?".
Well, the problems with the information provided by `rustc` appeared shortly:
- `rustc` warnings are `flycheck` warnings, which are slightly aside from our diagnostics with fixes.
When we map flycheck diagnostic to LSP, we can convert it into a fix, but only if it's marked as `Applicability::MachineApplicable`.
Name case fix is marked `Applicability::MaybeIncorrect`, and for a reason: it only suggest to rename symbol under cursor, without tracking any references.
- Warning spawned by `rustc` are identified by string labels rather than enum. It means that if one day the diagnostic will be renamed in `rustc`, `rust-analyzer` code will still compile, but won't find the required diagnostic by name anymore. If by chance this will happen when some unlucky guy will decide to create their first pull request, they'll be confused by suddenly failing tests (likely) not related to their changes.
- Even if we'll try to build fixes atop of `rustc` warnings, we'll have to do it in the `rust_analyzer::diagnostics::to_proto` module, which is far less
convenient for that matter than `ide` crate.
That's why I decided that it's worth a separate `rust-analyzer` diagnostic, which will implement `DiagnosticWithFix` trait.
After that, I discovered that currently `hir_ty::diagnostics` only check `DefWithBody` types, like function bodies. I had to add support for diagnostics
which look at any `ModuleDef`.
And of course, since I'd added a lot of new functionality, it required extensive testing.
That explains why the diff is so big for a (looking) relatively small feature.
I hope that this PR doesn't only add a small feature, but also creates a base for building another features.
## Example:
P.S. My eyes were bleeding when I had to write the code for the example...
6135: when generating new function, focus on return type instead of body r=matklad a=bnjjj
I made a little change when we use the assist to generate a new function, instead of focusing on the function body, it will focus on return type
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6205: Fix iterator hint shortening heuristic r=SomeoneToIgnore a=Veykril
Turns out I made a mistake with the heuristic check which is always true, so all iterators exposed from `core` were shortened, including things like ranges. 😅
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6153: Improve prime_caches and display its progress r=matklad a=jonas-schievink
It now computes the `CrateDefMap` of all crates, which is generally a reasonable approximation for "IDE features ready". There is still some delay after this finishes, I suspect mostly due to impl collection, which takes a while, but this should be an improvement already.
For more accurate progress reports, this topologically sorts all crates before starting this operation. ~~Because that is also the ordering in which parallelization makes sense (which was previously attempted in https://github.com/rust-analyzer/rust-analyzer/pull/3529), I decided to throw that into the mix as well. It still doesn't provide *that* much of a performance boost, but it does scale beyond the current single-core architecture, and adding it was very easy.~~
~~Unfortunately, as written, this will not tell the user which crate is actually causing slowdowns, since the displayed crate is the last one that was *started*, not the one we are currently *blocked* on, but that seems fairly difficult to implement unless I'm missing something.~~
(I have removed rayon for now since it does not work correctly with cancellation.)
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6198: Skip macro matcher fragment name semantic highlighting r=matklad a=Veykril
Implements a small state-machine for macro_rules! highlighting to separate out the matcher part of its rules. This skips semantically highlighting names of metavariables in the matcher and expander. This might even allow for more fun macro highlighting things in the future.
Fixes#4380.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6199: Fix `mut self` not emitting mutable binding on `self` use r=matklad a=Veykril
Prior to this, when `self` in a function is taken by value and bound mutably, its use inside of the method body won't be marked `mutably`.
Fixes#5461
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5917: Add a command to open docs for the symbol under the cursor r=matklad a=zacps
#### Todo
- [ ] Decide if there should be a default keybind or context menu entry
- [x] Figure out how to get the documentation path for methods and other non-top-level defs
- [x] Design the protocol extension. In future we'll probably want parameters for local/remote documentation URLs, so that should maybe be done in this PR?
- [x] Code organisation
- [x] Tests
Co-authored-by: Zac Pullar-Strecker <zacmps@gmail.com>
Return an error with a meaningful message for requests to
`textDocument/rename` if the operation cannot be performed.
Pass errors raised by rename handling code to the LSP runtime.
As a consequence, the VS Code client shows and logs the request
as if a server-side programming error occured.
Resolves https://github.com/rust-analyzer/rust-analyzer/issues/3981
Previously, "find all references" on a variant field wouldn't find any
references outside the defining module. This is because variant fields
were incorrectly assumed to be private, like struct fields without
explicit visibility, but they actually inherit the enum's visibility.
5651: Add track_env_var to the proc macro server r=kjeremy a=lnicola
See https://github.com/rust-lang/rust/pull/74653.
Fixes#6054.
Fixes#5640, maybe.
Should be merged when 1.47 is released.
Proc macros still don't work for me, but it no longer crashes.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Currently a method only has defaultness if it is a provided trait
method, but this will change when specialisation is available and may
need to become a concept known to hir.
I opted to go for a 'fewest changes' approach given specialisation is
still under development.
6161: Bump chalk to use latest git to get upstream fix r=jonas-schievink a=Ameobea
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
Co-authored-by: Casey Primozic <me@ameo.link>
6154: Shorten type hints for std::iter Iterators r=SomeoneToIgnore a=Veykril
Fixes#3750.
This re-exports the `hir_expand::name::known` module to be able to fetch the `Iterator` and `iter` names.
I'm not sure if there is anything to do with `Solution::Ambig` in `normalize_trait_assoc_type` or whether discarding those results is always wanted.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Percentage is a UI concern, the physical fact here is fraction. It's
sad that percentage bleeds into the protocol level, we even duplicated
this bad API ourselves!
6158: Fix for negative literals in macros r=matklad a=cutsoy
_This pull request fixes #6028._
When writing `-42.0f32` in Rust, it is usually parsed as two different tokens (a minus operator and a float literal).
But a procedural macro can also generate new tokens, including negative [float literals](https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.f32_suffixed):
```rust
#[proc_macro]
fn example_verbose(input: TokenStream) -> TokenStream {
let literal = Literal::f32_suffixed(-42.0);
quote! { #literal }
}
```
or even shorter
```rust
#[proc_macro]
fn example(input: TokenStream) -> TokenStream {
let literal = -42.0f32;
quote! { #literal }
}
```
Unfortunately, these currently cause RA to crash:
```
thread '<unnamed>' panicked at 'Fail to convert given literal Literal {
text: "-42.0f32",
id: TokenId(
4294967295,
),
}', crates/mbe/src/subtree_source.rs:161:28
```
This pull request contains both a fix 8cf9362 and a unit test 27798ee. In addition, I installed the patched server with `cargo xtask install --server` and verified in VSCode that it no longer crashes when a procedural macro returns a negative number literal.
Co-authored-by: Tim <tim@glacyr.com>
* Chalk very recently (like an hour ago) merged a fix that prevents rust analyzer from panicking. This allows it to be usable again for code that hits those situations. See #6134, #6145, Probably #6120
6124: Better normalized crate name usage r=jonas-schievink a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5343
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5932
Uses normalized name for code snippets (to be able to test the fix), hover messages and documentation rewrite links (are there any tests for those?).
Also renamed the field to better resemble the semantics.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
6139: Make find_path_prefixed configurable r=matklad a=Veykril
This makes `find_path_prefixed` more configurable allowing one to choose whether it always returns absolute paths, self-prefixed paths or to ignore local imports when building the path.
The config names are just thrown in here, taking better names if they exist :)
This should fix#6131 as well?
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6111: Add assist for converting the base of integer literals. r=SomeoneToIgnore a=vlakreeh
This PR adds an assist similar to Intellij's [convert number to](https://i.imgur.com/JH6wstP.png). It also does a small refactor to [assists/src/tests.rs](fc34403018/crates/assists/src/tests.rs) to add the ability to specify the resolved assist for a specific action within an assist group.
## Demo
Co-authored-by: vlakreeh <zeb@zebulon.dev>
6127: Correctly complete items with leading underscore r=SomeoneToIgnore a=fmease
Fixes#6091. Let me know if the test is placed into the right file or if it is even desired.
Co-authored-by: León Orell Valerian Liehr <liehr.exchange@gmx.net>
This removes all markdown when the client does not support the markdown MarkupKind
Otherwise the output on the editor will have some markdown boilerplate, making it less readable
This seems like a better factoring logically; ideally, clients shouldn't touch
`set_` methods of the database directly. Additionally, I think this
should remove the unfortunate duplication in fixture code.
5954: Add flexible configuration for runnables r=popzxc a=popzxc
This PR introduces two new configuration options for runnables: `overrideCargo` and `cargoExtraArgs`.
These options are applied to all the "run" tasks of rust analyzer, such as binaries and tests.
Overall motivation is that rust-analyzer provides similar options, for example, for `rustfmt`, but not for runnables.
## `overrideCargo`
This option allows user to replace `cargo` command with something else (well, something that is compatible with the cargo arguments).
Motivation is that some projects may have wrappers around cargo (or even whole alternatives to cargo), which do something related to the project, and only then run `cargo`. With this feature, such users will be able to use lens and run tests directly from the IDE rather than from terminal.
## `cargoExtraArgs`
This option allows user to add any additional arguments for `cargo`, such as `--release`.
It may be useful, for example, if project has big integration tests which take too long in debug mode, or if any other `cargo` flag has to be passed.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
6105: Fix path comparison not comparing paths correctly with unequal lengths r=matklad a=Veykril
~~This PR includes the commit from #6102 there as I found a bug while writing that(so either merging this or both in order works) so I included a test there already which was just ignored.~~ This PR fixes that, basically inserting imports didn't consider path length for equality, so depending on the order it might insert the path before or after another import if they only differ in segment length.
~~Diff without the commit of #61022d90d3937d~~
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6019: Remove make::path_from_text r=matklad a=Veykril
This removes the `make::path_from_text` function, which according to a note should've been private. I removed it since it didn't really serve a purpose as it was simply wrapping `make::ast_from_text`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6033: Make name resolution resolve proc macros instead of relying purely on the build system r=matklad a=jonas-schievink
This makes name resolution look at proc-macro declaration attributes like `#[proc_macro_derive]` and defines the right proc macro in the macro namespace, fixing unresolved custom derives like `thiserror::Error` (which can cause false positives, now that we emit diagnostics for unresolved imports).
This works even when proc-macro support is turned off, in which case we fall back to a dummy expander that always returns an error. IMO this is the right way to handle at least the name resolution part of proc. macros, while the *expansion* itself should rely on the build system to build and provide the macro DLL. It does mean that they may go out of sync, but we can provide diagnostics if that happens (something like "could not find macro X in crate Y – ensure that all files of crate Y are saved").
I think it is valuable to be able to reason about proc macros even when we can't expand them, since proc macro expansion can break between Rust releases or users might not want to turn it on for performance reasons. It allows us to provide better diagnostics on any proc macro invocation we're not expanding (like a weak warning that informs the user that proc macro support is turned off, or that it has been disabled because the server crashed).
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5763
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6085: Mark unresolved imports diagnostic as experimental r=jonas-schievink a=jonas-schievink
It causes a lot of false positives for people. We collected all of the known ones during the last week.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6073: Dont unnecessarily unnest imports r=matklad a=Veykril
Fixes#6071
This has the side effect that paths that refer to items inside of the current module get prefixed with `self`. Changing this behavior is unfortunately not straightforward should it be unwanted, though I don't see a problem with this as prefixing imports like this with `self` is what I do personally anyways 😅. You can see what I mean with this in one of the tests which had to be changed in `crates/ssr/src/tests.rs`.
There is one test that i still have to look at though, ~~which I by accident pushed with `#[ignore]` on it~~, which is `different_crate_renamed`, for some reason this now doesn't use the crate alias. This also makes me believe that aliases in general will break with this. So maybe this is not as straight forwards as I'd hoped for, but I don't really know how aliases work here.
Edit: The failing test should work now
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6055: Add ok postfix completion r=matklad a=mullr
Wrapping values in `Ok(...)` is so pervasive that it seems reasonable for it to
have its own postfix completion.
Co-authored-by: Russell Mull <russell.mull@gmail.com>
5846: Add references to fn args during completion r=matklad a=adamrk
When completing a function call, if there is an argument taken as a ref or mut ref which matches the name and type of a variable in scope, we will insert a `&` or `&mut` when filling in the function arguments. This addresses https://github.com/rust-analyzer/rust-analyzer/issues/5449.
E.g.
```rust
fn foo(x: &i32) {}
fn main() {
let x = 5;
foo # completing foo here generates `foo(&x)` now instead of `foo(x)`
}
```
Co-authored-by: adamrk <ark.email@gmail.com>
6043: Allow missing trait members assist without needing braces r=matklad a=M-J-Hooper
Assist to complete missing items when implementing a trait does not appear without impl def braces (see #5144 ).
The reason behind this was that this assist is based on `ast::AssocItemList` which only appears in the AST after the braces are added to the impl def.
Instead of relying on and replacing the item list, we now instead replace the entire `ast::Impl` and add the item list if its missing.
Co-authored-by: Matt Hooper <matthewjhooper94@gmail.com>
6018: Correct project_root path for ProjectJson. r=jonas-schievink a=woody77
It was already the folder containing the rust-project.json file, not the file itself. This also removes the Option-ness of it, since it's now an infallible operation to set the member value.
Co-authored-by: Aaron Wood <aaronwood@google.com>
6036: Don't re-read open files from disk when reloading a workspace r=kjeremy a=lnicola
Fixes#5742Fixes#4263
or so I hope.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
6017: Don't return any TextEdit if formatting is unchanged r=jonas-schievink a=cuviper
I found that `textDocument/formatting` was always returning a full
`TextEdit` replacement, even when there are no changes, which caused Vim
(w/ vim-lsp) to always indicate a modified buffer after formatting. We
can easily compare whether there were changes and return `null` if not,
so the client knows there's nothing to do.
Co-authored-by: Josh Stone <cuviper@gmail.com>
6016: Emit diagnostics for unresolved imports and extern crates r=jonas-schievink a=jonas-schievink
AFAIK, we don't have any major bugs in name resolution that would cause a lot of false positives here (except procedural attribute macro support and some rare issues around `#[path]` on module files), so these are *not* marked as experimental diagnostics right now.
I noticed that diagnostics in a file sometimes don't get displayed after opening, but require some edit to be performed. This seems like a preexisting issue though.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
5989: Rewrite import merging r=jonas-schievink a=Veykril
Rewrites how import merging is being handled. It is now a recursive function to properly handle merging of intermediate levels in the import trees. With this ordering the imports is also now possible tho it doesn't quite order it the same way as `rustfmt` does yet, namely it orders lowercase identifiers after uppercase identifiers as that is the standard character order that rust uses. This also fixes a few weird behaviors that were visible in some of the `replace_qualified_name_with_use.rs` tests.
This really took longer than I was hoping for, fighting with import trees is quite the exhausting task 😅
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6013: Add support for custom flycheck commands with JSON project workspaces r=jonas-schievink a=woody77
Enable flychecks with JSON project workspaces if an override command was provided as part
of the client configuration:
```
"rust-analyzer.checkOnSave.enable": true,
"rust-analyzer.checkOnSave.overrideCommand": ["custom_tool", "arg1", "arg2"],
```
Co-authored-by: Aaron Wood <aaronwood@google.com>
I found that `textDocument/formatting` was always returning a full
`TextEdit` replacement, even when there are no changes, which caused Vim
(w/ vim-lsp) to always indicate a modified buffer after formatting. We
can easily compare whether there were changes and return `null` if not,
so the client knows there's nothing to do.
5976: Complete trait impl immediately after type/const/fn r=jonas-schievink a=oxalica
Currently, we can complete type/const/fn but only if we typed an identifier.
That is, `impl .. { fn f<|> }` has completions with all trait fn including `f`, but `impl .. { fn <|> }` doesn't provide any suggestion (even if explicit trigger it).
This PR tweak the logic of completion match to make it possible.
However, we still need to explicit trigger suggestions (`Control + Space` by default) in vscode to show. Not sure if we can make it automatically triggered after typing the space after `fn`.
Another question is that I cannot figure out why `BLOCK_EXPR` need to be checked. A block expr directly inside a impl block should be invalid, and nested items will failed to locate impl block in specific offset and skip the suggestion. Now I simply removed it and no tests are broken.
4f91478e50/crates/ide/src/completion/complete_trait_impl.rs (L109)
Co-authored-by: oxalica <oxalicc@pm.me>
5985: Make MergeBehaviour configurable r=jonas-schievink a=Veykril
This should make the newly implemented `MergeBehaviour` for import insertion configurable as roughly outlined in https://github.com/rust-analyzer/rust-analyzer/pull/5935#issuecomment-685834257. For the config name and the like I just picked what came to mind so that might be up for bikeshedding.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5971: Implement async blocks r=flodiebold a=oxalica
Fix#4018
@flodiebold already gave a generic guide in the issue. Here's some concern about implementation detail:
- Chalk doesn't support generator type yet.
- Adding generator type as a brand new type (ctor) can be complex and need to *re-introduced* builtin impls. (Like how we implement closures before native closure support of chalk, which is already removed in #5401 )
- The output type of async block should be known after type inference of the whole body.
- We cannot directly get the type from source like return-positon-impl-trait. But we still need to provide trait bounds when chalk asking for `opaque_ty_data`.
- During the inference, the output type of async block can be temporary unknown and participate the later inference.
`let a = async { None }; let _: i32 = a.await.unwrap();`
So in this PR, the type of async blocks is inferred as an opaque type parameterized by the `Future::Output` type it should be, like what we do with closure type.
And it really works now.
Well, I still have some questions:
- The bounds `AsyncBlockImplType<T>: Future<Output = T>` is currently generated in `opaque_ty_data`. I'm not sure if we should put this code here.
- Type of async block is now rendered as `impl Future<Output = OutputType>`. Do we need to special display to hint that it's a async block? Note that closure type has its special format, instead of `impl Fn(..) -> ..` or function type.
Co-authored-by: oxalica <oxalicc@pm.me>
5955: Remove merge import code duplication r=jonas-schievink a=Veykril
This removes the code duplication caused by #5935, this also allows the assist to merge imports that have equal visibility and prevents merges of unequal visibility. This PR also fixes an iteration mistake in the mentioned PR:
Turns out I made a mistake when writing the `segment_iter` function, I was assuming that the `children` of a path will just be the segments, which is obviously not the case. This also brings insertion order of shorter paths in line with how `rustfmt` orders them.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
5951: Rename record_field_pat to record_pat_field r=jonas-schievink a=pksunkara
The token was renamed but not this.
5975: Report better errors in project.json/sysroot r=jonas-schievink a=jonas-schievink
This does a bunch of light refactoring so that the `Sysroot` is loaded later, which makes sure that any errors are reported to the user. I then added a check that reports an error if libcore is missing in the loaded sysroot. Since a sysroot without libcore is very useless, this indicates a configuration error.
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
5957: Add consuming modifier to lvalues that are passed by value and not Copy r=jonas-schievink a=Nashenas88
Related to #5856
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5956: Highlight errors in macros r=jonas-schievink a=popzxc
Resolves#4924
This PR makes rust-analyzer highlight not only the source place when error originates in macro, but also the exact places in macro which caused an error.
This is done by creating an inverse diagnostic, which points to the macro and cross-references the source place.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
5968: Lookup ADT and associated type names for chalk debugging / tweak chalk interner r=flodiebold a=nathanwhit
This PR improves the chalk program writing integration by looking up the names for ADTs and associated types, making the output much more readable.
There are also a few small changes to the interner, which gives some nice performance improvements. We clone `Ty`s and `ProgramClause`s relatively often in chalk, so wrapping them in `Arc`s is a perf win. This takes the time for performing type inference on the rust-analyzer codebase from 40s to 33s on my machine.
Co-authored-by: Nathan Whitaker <nathan.whitaker01@gmail.com>
5940: Implement "Replace `impl Trait` function argument with the named generic" assist. r=matklad a=alekseysidorov
Fixes#5085
Co-authored-by: Aleksei Sidorov <gorthauer87@yandex.ru>
5935: Rewrite import insertion r=matklad a=Veykril
This is my attempt at refactoring the import insertion #3947. I hope what I created here is somewhat in line with what was requested, it wouldn't surprise me .
`common_prefix` is a copy from `merge_imports.rs` so those should be unified somewhere, `try_merge_trees` is also copied from there but slighly modified to take the `MergeBehaviour` enum into account.
`MergeBehaviour` should in the end become a configuration option, and the order if `ImportGroup` probably as well?
I'm not too familiar with the assist stuff and the like which is why I dont know what i have to do with `insert_use_statement` and `find_insert_use_container` for now.
I will most likely add more test cases in the end as well as I currently only tried to hit every path in `find_insert_position`.
Some of the merge tests also fail atm due to them not sorting what they insert. There is also this test case I'm not sure if we want to support it. I would assume we want to? https://github.com/rust-analyzer/rust-analyzer/pull/5935/files#diff-6923916dd8bdd2f1ab4b984adacd265fR540-R547
The entire module was rewritten so looking at the the file itself is probably better than looking at the diff.
Regarding the sub issues of #3947:
- #3301: This is fixed with the rewrite, what this implementation does is that it scans through the first occurence of groupings and picks the appropriate one out. This means the user can actually rearrange the groupings on a per file basis to their liking. If a group isnt being found it is inserted according to the `ImportGroup` variant order(Would be nice if this was configurable I imagine).
- #3831: This should be fixed with the introduced `MergeBehaviour` enum and it's `Last` variant.
- #3946: This should also be [fixed](https://github.com/rust-analyzer/rust-analyzer/pull/5935/files#diff-6923916dd8bdd2f1ab4b984adacd265fR87)
- #5795: This is fixed in the sense that the grouping search picks the first group that is of the same kind as the import that is being added. So if there is a random import in the middle of the program it should only be considered if there is no group of the same kind in the file already present.
- the last point in the list I havent checked yet, tho I got the feeling that it's not gonna be too simple as that will require knowledge of whether in this example `ast` is a crate or the module that is already imported.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
`hir` should know nothing about URLs, markdown and html. It should
only be able to:
* resolve stringy path from documentation
* generate canonical stringy path for a def
In contrast, link rewriting should not care about semantics of paths
and names resolution, and should be concern only with text mangling
bits.
5893: Allow running a test as a binary r=matklad a=jonas-schievink
If a test uses `harness = false`, it just contains an `fn main` that is executed via `cargo test`. This adds support for that.
Note though that Cargo doesn't actually tell us whether `harness = false`, so this hint will always show up when you put an `fn main` into an integration test. Normally people shouldn't be doing that if they do use the harness though.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
