3778: Use more functional programming in ArenaMap::insert r=matklad a=kjeremy
I find this more readable and it flattens out the body a little. Others may disagree.
Co-authored-by: kjeremy <kjeremy@gmail.com>
3781: Add crate versions when running cargo -p commands. r=matklad a=o0Ignition0o
If someone (unfortunately) creates a project that happens to have the same name as one of its (future) dependencies, there is [a way for them to change the dependency's alias in the Cargo.toml file](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#renaming-dependencies-in-cargotoml), to mitigate the name conflict. Unfortunately cargo -p commands don't seem to pick it up, which seems to put rust-analyzer run commands in a tough situation:
```
> Executing task: cargo test --package config --example default -- tests --nocapture <
error: There are multiple `config` packages in your project, and the specification `config` is ambiguous.
Please re-run this command with `-p <spec>` where `<spec>` is one of the following:
config:0.1.0
config:0.9.3
The terminal process terminated with exit code: 101
```
cargo suggests us to be more specific and refer to a package by its name and version, which this PR achieves.
I passed the version as a String because I don't really understand how the ra_db types work, but I would love to switch it to [a fully fledged Version type](https://steveklabnik.github.io/semver/semver/index.html) if you guide me towards that :)
Co-authored-by: o0Ignition0o <jeremy.lempereur@gmail.com>
Until now cargo commands with the -p flag would pass the package name only.
It doesn't play super well with the toml Renaming dependencies feature.
This commit specifies the package name and version when a cargo command is run with the -p flag,
to avoid ambiguities.
This commit changes the parser to attach doc-comments to the corresponding declaration in case there are newlines in between the doc-comment and the declaration.
3761: Append new match arms rather than replacing all of them r=matklad a=mattyhall
This means we now retain comments when filling in match arms. This fixes#3687. This is my first contribution so apologies if it needs a rethink! I think in particular the way I find the position to append to and remove_if_only_whitespace are a little hairy.
Co-authored-by: Matthew Hall <matthew@quickbeam.me.uk>
3727: Introduce ra_proc_macro r=matklad a=edwin0cheng
This PR implemented:
1. Reading dylib path of proc-macro crate from cargo check , similar to how `OUTDIR` is obtained.
2. Added a new crate `ra_proc_macro` and implement the foot-work for reading result from external proc-macro expander.
3. Added a struct `ProcMacroClient` , which will be responsible to the client side communication to the External process.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3722: Fix parsing lambdas with return type r=matklad a=matklad
We should eat only a single block, and not whatever larger expression
may start with a block.
closes#3721
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3707: Add ItemScope::visibility_of r=matklad a=edwin0cheng
~This PR implements `HasVisibility` for various constructs and change `Definition::search_scope` to use `Visibility` directly instead of depends on ad-hoc string parsing.~
This PR added `visibility_of` in `ItemScope` and `Module` and use it directly directly instead of depends on ad-hoc string parsing.
And also add a FIXME to indicate that there is a bug which do not search child-submodules in other files recursively in `Definition::search_scope`.
I will submit another PR to fix that bug after this is merged.
cc @flodiebold
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3664: Introduce TokenConverter Trait r=matklad a=edwin0cheng
This PR add a `TokenConverter` Trait to share the conversion logic between raw `lexer` token and Syntax Node Token.
Related #2158.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3700: fill match arms with empty block rather than unit tuple r=matklad a=JoshMcguigan
As requested by @Veetaha in #3689 and #3687, this modifies the fill match arms assist to create match arms as an empty block `{}` rather than a unit tuple `()`.
In one test I left one of the pre-existing match arms as a unit tuple, and added a body to another match arm, to demonstrate that the contents of existing match arms persist.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3696: vscode: more type safety r=matklad a=Veetaha
3698: Consider references when applying postfix completions r=matklad a=SomeoneToIgnore
Sometimes my RA debugging workflow breaks because `.dbg` is applied to the variable that is used later in the code.
It's safer to consider the refences to avoid this for completions that may trigger the move.
3703: Don't try to enable proposed API's on stable r=matklad a=matklad
bors r+
🤖
Co-authored-by: veetaha <veetaha2@gmail.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3689: implement fill match arm assist for tuple of enums r=matklad a=JoshMcguigan
This updates the fill match arm assist to work in cases where the user is matching on a tuple of enums.
Note, for now this does not apply when some match arms exist (other than the trivial `_`), but I think this could be added in the future.
I think this also lays the groundwork for filling match arms when matching on tuples of non-enum values, for example a tuple of an enum and a boolean.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3632: ra_cargo_watch: log errors r=matklad a=Veetaha
Until this moment we totally ignored all the errors from cargo process. Though this is still true, but we
now try to log ones that are critical (i.e. misconfiguration errors and ignore compile errors).
This fixes#3631, and gives us a better error message to more gracefully handle the #3265
Though I think that outputting this only to `Output` channel is not enough. We should somehow warn the user that he passed wrong arguments to `cargo-watch.args`. I didn't bother looking for how to do this now, but this PR at least gives us something.
*cc* @kiljacken @matklad
Co-authored-by: veetaha <veetaha2@gmail.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
As stated by matklad, reading the stderr
should be done alngside with
stdout via select() (or I guess poll()),
there is no such implementation in stdlib,
since it is quite low level and platform-dependent and it
also requires quite a bit of unrelated code we don't use it for now.
As referenced by bjorn3, there is an implementation of the needed read2() function
in rustc compiletest. The better solution will be to extract this function
to a separate crate in future:
https://github.com/rust-analyzer/rust-analyzer/pull/3632#discussion_r395605298
3671: Add identity expansion checking in ill-form expansion r=flodiebold a=edwin0cheng
This PR try to add more checking code in error case in macro expansion. The bug in #3642 is introduced by #3580 , which allow ill-form macro expansion in *all* kind of macro expansions.
In general we should separate hypothetical macro expansion and the actual macro expansion call. However, currently the `Semantic` workflow we are using only support single macro expansion type, we might want to review it and make it works in both ways. (Maybe add a field in `MacroCallLoc` for differentiation)
Fix#3642
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3623: 'Fill match arms' should work with existing match arms r=matklad a=slyngbaek
Addresses #3039
This essentially adds missing match arms. The algorithm for this
can get complicated rather quickly so bail in certain conditions
and rely on a PlaceholderPat.
The algorighm works as such:
- Iterate through the Enum Def Variants
- Attempt to see if the variant already exists as a match arm
- If yes, skip the enum variant. If no, include it.
- If it becomes complicated, rather than exhaustively deal with every
branch, mark it as a "partial match" and simply include the
placeholder.
Conditions for "complication":
- The match arm contains a match guard
- Any kind of nested destrucuring
Order the resulting merged match branches as such:
1. Provided match arms
2. Missing enum variant branch arms
3. End with Placeholder if required
- Add extra tests
Co-authored-by: Steffen Lyngbaek <steffenlyngbaek@gmail.com>
Iterate through TupleStructPat's until a MatchArm if
one exists. Store in a new is_pat_bind_and_path bool
and allow the `complete_scope` to find matches.
Added some tests to ensure it works in simple and nested cases.
Addresses #3039
This essentially adds missing match arms. The algorithm for this
can get complicated rather quickly so bail in certain conditions
and rely on a PlaceholderPat.
The algorighm works as such:
- Iterate through the Enum Def Variants
- Attempt to see if the variant already exists as a match arm
- If yes, skip the enum variant. If no, include it.
- If it becomes complicated, rather than exhaustively deal with every
branch, mark it as a "partial match" and simply include the
placeholder.
Conditions for "complication":
- The match arm contains a match guard
- Any kind of nested destrucuring
Order the resulting merged match branches as such:
1. Provided match arms
2. Missing enum variant branch arms
3. End with Placeholder if required
- Add extra tests
It improves compile time in `--release` mode quite a bit, it doesn't
really slow things down and, conceptually, it seems closer to what we
want the physical architecture to look like (we don't want to
monomorphise EVERYTHING in a single leaf crate).
3573: Check all crates of the workspace r=matklad a=matklad
Previously, if the root of the was was a real crate, only this crate
was checked.
Ideally, we might want some kind of config here (which might be just
overriding the whole command), but `--workspace` is def a nicer
default.
r? @kiljacken
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3587: Use WorkDoneProgress LSP API for initial load r=matklad a=slyngbaek
Addresses #3283
Rather than using custom UI for showing the loaded state. Rely
on the WorkDoneProgress API in 3.15.0
https://microsoft.github.io/language-server-protocol/specification#workDoneProgress.
No client-side work was necessary. The UI is not exactly what is
described in the issue but afaict that's how VS Code implements the LSP
API.
- The WorkDoneProgressEnd does not appear to display its message
contents (controlled by vscode)
Co-authored-by: Steffen Lyngbaek <steffenlyngbaek@gmail.com>
3591: Support local macro_rules r=matklad a=edwin0cheng
This PR implement local `macro_rules` in function body, by adding following things:
1. While lowering, add a `MacroDefId` in body's `ItemScope` as a textual legacy macro.
2. Make `Expander::enter_expand` search with given `ItemScope`.
3. Make `Resolver::resolve_path_as_macro` search with `LocalItemScope`.
Fix#2181
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Addresses #3283
Rather than using custom UI for showing the loaded state. Rely
on the WorkDoneProgress API in 3.15.0
https://microsoft.github.io/language-server-protocol/specification#workDoneProgress.
No client-side work was necessary. The UI is not exactly what is
described in the issue but afaict that's how VS Code implements the LSP
API.
- The WorkDoneProgressEnd does not appear to display its message
contents (controlled by vscode)
3561: feat: add debug code lens r=matklad a=hdevalke
Refs #3539
3577: Protect against infinite macro expansion in def collector r=edwin0cheng a=flodiebold
Something I noticed while trying to make macro expansion more resilient against errors.
There was a test for this, but it wasn't actually working because the first recursive expansion failed. (The comma...)
Even with this limit, that test (when fixed) still takes some time to pass because of the exponential growth of the expansions, so I disabled it and added a different one without growth.
CC @edwin0cheng
Co-authored-by: Hannes De Valkeneer <hannes@de-valkeneer.be>
Co-authored-by: hdevalke <2261239+hdevalke@users.noreply.github.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
There was a test for this, but it wasn't actually working because the first
recursive expansion failed. (The comma...)
Even with this limit, that test (when fixed) still takes some time to pass
because of the exponential growth of the expansions, so I disabled it and added
a different one without growth.
The `ty` function in code_model returned the type with placeholders for type
parameters. That's nice for printing, but not good for completion, because
placeholders won't unify with anything else: So the type we got for `HashMap`
was `HashMap<K, V, T>`, which doesn't unify with `HashMap<?, ?, RandomState>`,
so the `new` method wasn't shown.
Now we instead return `HashMap<{unknown}, {unknown}, {unknown}>`, which does
unify with the impl type. Maybe we should just expose this properly as variables
though, i.e. we'd return something like `exists<type, type, type> HashMap<?0,
?1, ?2>` (in Chalk notation). It'll make the API more complicated, but harder to
misuse. (And it would handle cases like `type TypeAlias<T> = HashMap<T, T>` more
correctly.)
Previously, if the root of the was was a real crate, only this crate
was checked.
Ideally, we might want some kind of config here (which might be just
overriding the whole command), but `--workspace` is def a nicer
default.
3553: Completions do not show for function with same name as mod r=matklad a=JoshMcguigan
fixes#3444
I've added a test case in `crates/ra_ide/src/completion/complete_path.rs` which verifies the described behavior in #3444. Digging in, I found that [the module scope iterator](ba62d8bd1c/crates/ra_ide/src/completion/complete_path.rs (L22)) only provides the module `z`, and does not provide the function `z` (although if I name the function something else then it does show up here).
I thought perhaps the name wasn't being properly resolved, but I added a test in `crates/ra_hir_def/src/nameres/tests.rs` which seems to suggest that it is? I've tried to figure out how to bridge the gap between these two tests (one passing, one failing) to see where the function `z` is being dropped, but to this point I haven't been able to track it down.
Any pointers on where I might look for this?
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3543: Parameter inlay hint separate from variable type inlay? #2876 r=matklad a=slyngbaek
Add setting to allow enabling either type inlay hints or parameter
inlay hints or both. Group the the max inlay hint length option
into the object.
- Add a new type for the inlayHint options.
- Add tests to ensure the inlays don't happen on the server side
Co-authored-by: Steffen Lyngbaek <steffenlyngbaek@gmail.com>
3559: Implement builtin assert! macro r=matklad a=edwin0cheng
This PR add a dummy implementation for `assert!` macro, which mainly make `hover` and `goto-def` works on arguments inside it.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3564: Better handling of a few kinds of cargo/clippy diagnostics r=matklad a=kiljacken
This was initially supposed to just be a fix for #3433, but I caught a few things that ended up being useful as well.
This PR primarily makes us handle multi-edit fix suggestions properly. Instead of just applying the first fix we apply all the parts of the fix in a single action.
Second up, this PR handles diagnostics with multiple primary spans, f.x. the unused import diagnostic from rustc:
The LSP doesn't handle this too well, as it only support a single complete range for each diagnostic, so we get duplicate messages in the problem panel of VSCode:
However, I feel like the improved visual aspect in-editor outweighs the duplication in the problem panel. I'm open to not including the second commit if anybody really doesn't like the idea of duplicate diagnostics in the problem pane.
Fixes#3433Fixes#3257
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
