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>
Overlapping indels are a bug. Checking this *always* is tricky (needs
a sorted data structure to not suffer O(N^2) perf). But
opportunistically checking small indels should give provide 80% of the
benefits.
4873: Resolve links in hover documentation r=matklad a=zacps
This PR resolves links in hover documentation. Both the upcoming intra-doc-links style and the old "path-based" style.
## Todo
* [x] More tests
* [ ] Benchmark (Is there an easy way to benchmark this?)
* [x] ~~Resolve issues with the markdown parser/get rid of it~~ Migrate to `pulldown_cmark_to_cmark`
* [x] Reorganise code (Tips appreciated)
---
Fixes#503
Co-authored-by: Zac Pullar-Strecker <zacmps@gmail.com>
4776: Do a weekly minor publish to crates.io r=matklad a=pksunkara
This is the same system I set up on Chalk repo.
Every week it creates a new minor version, pushes it to github and then deploys it to crates.io.
Co-authored-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
5845: Omit lenses for not runnable doctests r=matklad a=SomeoneToIgnore
Ideally, we should properly parse the doctest attributes before, but since I need it for the code lens only, this way should suffice for now
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
We might want to provide more efficient impls for check if usages
exist, limiting the search, filtering and cancellation, so let's
violate YAGNI a bit here.
Main one: instead of adding a parameter to function to handle special
case, make the caller handle it.
Second main one: make sure that function does a reasonable thing.
`highlight_def` picks a color for def, *regardless* of the context
the def is use. Feeding an info from the call-site muddies the
responsibilities here.
Minor smells, flagging the function as having space for improvement in
the first place:
* many parameters, some of which are set as constants on most
call-sites (introduce severalfunction instad)
* boolean param (add two functions instead)
5643: Add new consuming modifier, apply consuming and mutable to methods r=matklad a=Nashenas88
This adds a new `consuming` semantic modifier for syntax highlighters.
This also emits `mutable` and `consuming` in two cases:
- When a method takes `&mut self`, then it now has `function.mutable` emitted.
- When a method takes `self`, and the type of `Self` is not `Copy`, then `function.consuming` is emitted.
CC @flodiebold
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
5695: Added completion for unstable features r=matklad a=Fihtangolz
Added xtask for downloading list of unstable features from the unstable book and codegen for it. Also included small changes from linter.
Co-authored-by: Dmitry <mamhigtt@gmail.com>
Co-authored-by: Dmitry Opokin <mamhigtt@gmail.com>
5682: Add an option to disable diagnostics r=matklad a=popzxc
As far as I know, currently it's not possible to disable a selected type of diagnostics provided by `rust-analyzer`.
This causes an inconvenient situation with a false-positive warnings: you either have to disable all the diagnostics, or you have to ignore these warnings.
There are some open issues related to this problem, e.g.: https://github.com/rust-analyzer/rust-analyzer/issues/5412, https://github.com/rust-analyzer/rust-analyzer/issues/5502
This PR attempts to make it possible to selectively disable some diagnostics on per-project basis.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
5687: Fix document symbols order r=matklad a=magurotuna
Resolves#5655
And adds tests for `handle_document_symbol`, both with `hierarchical_symbols` enabled and with it disabled.
Previously document symbols were displayed in reverse order in sublime text with its LSP plugin, but this patch fixes it like this:
Co-authored-by: Yusuke Tanaka <yusuktan@maguro.dev>
5758: SSR: Explicitly autoderef and ref placeholders as needed r=matklad a=davidlattimore
Structural search replace now inserts *, & and &mut in the replacement to match any auto[de]ref in the matched code.
e.g. `$a.foo() ==>> bar($a)` might convert `x.foo()` to `bar(&mut x)`
Co-authored-by: David Lattimore <dml@google.com>
The idea here is that, on CI, we only want to cache crates.io
dependencies, and not local crates. This keeps the size of the cache
low, and also improves performance, as network and moving files on
disk (on Windows) can be slow.
5776: Fix eslint errors on .eslintrc.js and rollup.config.js r=matklad a=fuafa
Eslint complains if these two files does not include in the `tsconfig.json`.
```
Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: .eslintrc.js.
The file must be included in at least one of the projects provided.eslint
```
5780: Fixup whitespace when adding missing impl items r=matklad a=jDomantas
Generate properly formatted whitespace when adding impl items - with an empty line between items and removing extra whitespace that often appears at the end.
This is my first time working on rust analyzer so I'm not very familiar with its internal APIs. If there's a better way to do such syntax tree editing I'd be glad to hear it.
Co-authored-by: xiaofa <xiaofalzx@gmail.com>
Co-authored-by: jDomantas <djadenkus@gmail.com>
5766: Hacky support for fn-like proc macros r=matklad a=jonas-schievink
It turns out that this is all that's needed to get something like this working:
```rust
#[proc_macro]
pub fn function_like_macro(_args: TokenStream) -> TokenStream {
TokenStream::from_str("fn fn_success() {}").unwrap()
}
```
```rust
function_like_macro!();
fn f() {
fn_success();
}
```
The drawback is that it also makes this work, because there is no distinction between different proc macro kinds in the rest of r-a:
```rust
#[derive(function_like_macro)]
struct S {}
fn f() {
fn_success();
}
```
Another issue is that it seems to panic, and then panic, when using this on the rustc code base, due to some issue in the inscrutable proc macro bridge code.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Conjecture: it's impossible to use hir::Path *correctly* from an IDE.
I am not entirely sure about this, and we might need to add it back at
some point, but I have to arguments that convince me that we probably
won't:
* `hir::Path` has to know about hygiene, which an IDE can't set up
properly.
* `hir::Path` lacks identity, but you actually have to know identity
to resolve it correctly
