The sytax tree output files now use .rast extension
(rust-analyzer syntax tree or rust abstract syntax tree
(whatever)).
This format has a editors/code/ra_syntax_tree.tmGrammar.json declaration
that supplies nice syntax highlighting for .rast files.
3843: Remove rustc_lexer dependency in favour of rustc-ap-rustc_lexer r=est31 a=est31
The latter is auto-published on a regular schedule (Right now weekly).
See also https://github.com/alexcrichton/rustc-auto-publish
Co-authored-by: est31 <MTest31@outlook.com>
3829: Adds to SSR match for semantically equivalent call and method call r=matklad a=mikhail-m1
#3186
maybe I've missed some corner cases, but it works in general
Co-authored-by: Mikhail Modin <mikhailm1@gmail.com>
In textmate, keyword.control is used for all kinds of things; in fact,
the default scope mapping for keyword is keyword.control!
So let's add a less ambiguous controlFlow modifier
See Microsoft/vscode#94367
The big change here is counting binders, not
variables (https://github.com/rust-lang/chalk/pull/360). We have to adapt to the
same scheme for our `Ty::Bound`. It's mostly fine though, even makes some things
more clear.
We treat macro calls as expressions (there's appropriate Into impl),
which causes problem if there's expresison and non-expression macro in
the same node (like in the match arm).
We fix this problem by nesting macor patterns into another node (the
same way we nest path into PathExpr or PathPat). Ideally, we probably
should add a similar nesting for macro expressions, but that needs
some careful thinking about macros in blocks: `{ am_i_expression!() }`.
3746: Add create_function assist r=flodiebold a=TimoFreiberg
The function part of #3639, creating methods will come later
- [X] Function arguments
- [X] Function call arguments
- [x] Method call arguments
- [x] Literal arguments
- [x] Variable reference arguments
- [X] Migrate to `ast::make` API
Done, but there are some ugly spots.
Issues to handle in another PR:
- function reference arguments: Their type isn't printed properly right now.
The "insert explicit type" assist has the same issue and this is probably a relatively rare usecase.
- generating proper names for all kinds of argument expressions (if, loop, ...?)
Without this, it's totally possible for the assist to generate invalid argument names.
I think the assist it's already helpful enough to be shipped as it is, at least for me the main usecase involves passing in named references.
Besides, the Rust tooling ecosystem is immature enough that some janky behaviour in a new assist probably won't scare anyone off.
- select the generated placeholder body so it's a bit easier to overwrite it
- create method (`self.foo<|>(..)` or `some_foo.foo<|>(..)`) instead of create_function.
The main difference would be finding (or creating) the impl block and inserting the `self` argument correctly
- more specific default arg names for literals.
So far, every generated argument whose name can't be taken from the call site is called `arg` (with a number suffix if necessary).
- creating functions in another module of the same crate.
E.g. when typing `some_mod::foo<|>(...)` when in `lib.rs`, I'd want to have `foo` generated in `some_mod.rs` and jump there.
Issues: the mod could exist in `some_mod.rs`, in `lib.rs` as `mod some_mod`, or inside another mod but be imported via `use other_mod::some_mod`.
- refer to arguments of the generated function with a qualified path if the types aren't imported yet
(alternative: run autoimport. i think starting with a qualified path is cleaner and there's already an assist to replace a qualified path with an import and an unqualified path)
- add type arguments of the arguments to the generated function
- Autocomplete functions with information from unresolved calls (see https://github.com/rust-analyzer/rust-analyzer/pull/3746#issuecomment-605281323)
Issues: see https://github.com/rust-analyzer/rust-analyzer/pull/3746#issuecomment-605282542. The unresolved call could be anywhere. But just offering this autocompletion for unresolved calls in the same module would already be cool.
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
3814: Add impl From for enum variant assist r=flodiebold a=mattyhall
Basically adds a From impl for tuple enum variants with one field. It was recommended to me on the zulip to maybe try using the trait solver, but I had trouble with that as, although it could resolve the trait impl, it couldn't resolve the variable unambiguously in real use. I'm also unsure of how it would work if there were already multiple From impls to resolve - I can't see a way we could get more than one solution to my query.
Fixes#3766
Co-authored-by: Matthew Hall <matthew@quickbeam.me.uk>
This commit is a fixup of a bug I introduced by using a PackageId to refer to a crate when its name conflicts with a dependency.
It turns out the package id currently is `name version path` while cargo expects `name:version` as argument.
Basically adds a From impl for tuple enum variants with one field. Added
to cover the fairly common case of implementing your own Error that can
be created from another one, although other use cases exist.
3806: lower bool literal value r=flodiebold a=JoshMcguigan
Following up on #3805, this PR adds the literal value to `ast::LiteralKind` so when we lower we can use the actual value from the source code rather than the default value for the type. Ultimately I plan to use this for exhaustiveness checking in #3706.
I didn't include this in the previous PR because I wasn't sure if it made sense to add this information to `ast::LiteralKind` or provide some other mechanism to get this from `ast::Literal`.
For now I've only implemented this for boolean literals, but I think it could be easily extended to other types. A possible exception to this are string literals, since we may not want to clone around an owned string to hold onto in `ast::LiteralKind`, and it'd be nice to avoid adding a generic lifetime as well. Perhaps we won't ever care about the actual value of a string literal?
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3797: Don't show chaining hints for record literals and unit structs r=matklad a=lnicola
Fixes#3796
r? @Veetaha
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
3805: lower literal patterns r=JoshMcguigan a=JoshMcguigan
While working on #3706 I discovered literal patterns weren't being lowered. This PR implements that lowering.
Questions for reviewers:
1. This re-uses the existing conversion from `ast::LiteralKind` to `Literal`, but `ast::LiteralKind` doesn't include information about the actual value of the literal, which causes `Literal` to be created with the default value for the type (rather than the actual value in the source code). Am I correct in thinking that we'd eventually want to change things in such a way that we could initialize the `Literal` with the actual literal value? Is there an existing issue for this, or else perhaps I should create one to discuss how it should be implemented? My main question would be whether `ast::LiteralKind` should be extended to hold the actual value, or if we should provide some other way to get that information from `ast::Literal`?
2. I couldn't find tests which directly cover this, but it does seem to work in #3706. Do we have unit tests for this lowering code?
3. I'm not sure why `lit.literal()` returns an `Option`. Is returning a `Pat::Missing` in the `None` case the right thing to do?
4. I was basically practicing type-system driven development to figure out the transformation from `ast::Pat::LiteralPat` to `Pat::Lit`. I don't have an immediate question here, but I just wanted to ensure this section is looked at closely during review.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3780: Simplify r=matklad a=Veetaha
I absolutely love tha fact that removing `.clone()` simplifies the code comparing to other languages where it's actually the contrary (ahem ~~`std::move()`~~)
3787: vscode: add syntax tree inspection hovers and highlights r=matklad a=Veetaha
I implemented the reverse mapping (when you hover in the rust editor), but it seems overcomplicated, so I removed it
Related #3682
Co-authored-by: veetaha <veetaha2@gmail.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
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>
- Instead of a single object type, use several individual nested types
to allow toggling from the settings GUI
- Remove unused struct definitions
- Install and test that the toggles work
3549: Implement env! macro r=matklad a=edwin0cheng
This PR implements `env!` macro by adding following things:
1. Added `additional_outdirs` settings in vscode. (naming to be bikeshed)
2. Added `ExternSourceId` which is a wrapping for SourceRootId but only used in extern sources. It is because `OUT_DIR` is not belonged to any crate and we have to access it behind an `AstDatabase`.
3. This PR does not implement the `OUT_DIR` parsing from `cargo check`. I don't have general design about this, @kiljacken could we reuse some cargo watch code for that ?
~~Block on [#3536]~~
PS: After this PR , we (kind of) completed the `include!(concat!(env!('OUT_DIR'), "foo.rs")` macro call combo. [Exodia Obliterate!](https://www.youtube.com/watch?v=RfqNH3FoGi0)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3542: Renames work on struct field shorthands r=matklad a=m-n
When renaming either a local or a struct field, struct field shorthands are now renamed correctly.
Happy to refactor this if it doesn't fit the design of the code. Thanks for adding the suggestion of where to start on the issue.
I wasn't sure if I should also look at the behavior of renaming when placing the cursor at the field shorthand; the following describes the behavior with this patch:
```rust
#[test]
fn test_rename_field_shorthand_for_unspecified() {
// when renaming a shorthand, should we have a way to specify
// between renaming the field and the local?
//
// If not is this the correct default?
test_rename(
r#"
struct Foo {
i: i32,
}
impl Foo {
fn new(i: i32) -> Self {
Self { i<|> }
}
}
"#,
"j",
r#"
struct Foo {
i: i32,
}
impl Foo {
fn new(j: i32) -> Self {
Self { i: j }
}
}
"#,
);
}
```
Resolves#3431
Co-authored-by: Matt Niemeir <matt.niemeir@gmail.com>
- Updated naming of config
- Define struct in ra_ide and use remote derive in rust-analyzer/config
- Make inlayConfig type more flexible to support more future types
- Remove constructor only used in tests
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
To test whether the receiver type matches for the impl, we unify the given self
type (in this case `HashSet<{unknown}>`) with the self type of the
impl (`HashSet<?0>`), but if the given self type contains Unknowns, they won't
be unified with the variables in those places. So we got a receiver type that
was different from the expected one, and concluded the impl doesn't match.
The fix is slightly hacky; if after the unification, our variables are still
there, we make them fall back to Unknown. This does make some sense though,
since we don't want to 'leak' the variables.
Fixes#3547.
3536: Add get and set for `Env` r=matklad a=edwin0cheng
This PR add three things :
1. Add `get` and `set` in `Env`.
2. Implement fixture meta for `with_single_file`.
3. Add `env` meta in fixture.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3526: Silence "file out of workspace" errors r=matklad a=matklad
We really should fix this limitation of the VFS, but it's some way off
at the moment, so let's just silence the user-visible error for now.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3513: Completion in macros r=matklad a=flodiebold
I experimented a bit with completion in macros. It's kind of working, but there are a lot of rough edges.
- I'm trying to expand the macro call with the inserted fake token. This requires some hacky additions on the HIR level to be able to do "hypothetical" expansions. There should probably be a nicer API for this, if we want to do it this way. I'm not sure whether it's worth it, because we still can't do a lot if the original macro call didn't expand in nearly the same way. E.g. if we have something like `println!("", x<|>)` the expansions will look the same and everything is fine; but in that case we could maybe have achieved the same result in a simpler way. If we have something like `m!(<|>)` where `m!()` doesn't even expand or expands to something very different, we don't really know what to do anyway.
- Relatedly, there are a lot of cases where this doesn't work because either the original call or the hypothetical call doesn't expand. E.g. if we have `m!(x.<|>)` the original token tree doesn't parse as an expression; if we have `m!(match x { <|> })` the hypothetical token tree doesn't parse. It would be nice if we could have better error recovery in these cases.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
3516: Handle visibility in more cases in completion r=matklad a=flodiebold
This means we don't show private items when completing paths or method calls.
We might want to show private items if we can edit their definition and provide a "make public" assist, but I feel like we'd need better sorting of completion items for that, so they can be not shown or sorted to the bottom by default. Until then, they're usually more of a distraction to me.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
3518: Add parse_to_token_tree r=matklad a=edwin0cheng
This PR introduce a function for parsing `&str` to `tt::TokenTree`:
```rust
// Convert a string to a `TokenTree`
pub fn parse_to_token_tree(text: &str) -> Option<(tt::Subtree, TokenMap)> {
````
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Allow trait autocompletions for unimplemented associated fn's, types,
and consts without using explicit keywords before hand (fn, type,
const).
The sequel to #3108.
3499: Resolve `Self::AssocTy` in impls r=matklad a=flodiebold
To do this we need to carry around the original resolution a bit, because `Self`
gets resolved to the actual type immediately, but you're not allowed to write
the equivalent type in a projection. (I tried just comparing the projection base
type with the impl self type, but that seemed too dirty.) This is basically how
rustc does it as well.
Fixes#3249.
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
To do this we need to carry around the original resolution a bit, because `Self`
gets resolved to the actual type immediately, but you're not allowed to write
the equivalent type in a projection. (I tried just comparing the projection base
type with the impl self type, but that seemed too dirty.) This is basically how
rustc does it as well.
Fixes#3249.
3494: Implement include macro r=matklad a=edwin0cheng
This PR implement builtin `include` macro.
* It does not support include as expression yet.
* It doesn't consider `env!("OUT_DIR")` yet.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3483: Unfold groups with single assists into plain assists r=matklad a=SomeoneToIgnore
A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/3120/files#r378788698 , made to show more detailed label when the assist group contains a single element
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
3482: Fix regression from #3451 r=matklad a=edwin0cheng
There is a regression from #3451 such that the following code has failed to parse in raw item collecting phase:
```rust
macro_rules! with_std {
($($i:item)*) => ($(#[cfg(feature = "std")]$i)*)
}
with_std! {
mod macros;
mod others;
}
```
### Rationale
We always assume the last token of an statement will not end with a whitespace, which is true. It is because in parsing phase, we always emit `SyntaxNode` before any whitespace. Such that in various parts of RA code, we solely check the semi-colon by using `SyntaxNode::last_child_token() == ";"` .
However, in #3451, we insert some whitespaces between puncts such that we broke above assumption. This PR fixed this bug by make sure we don't add any whitespace if it is a semicolon.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
