| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
https://github.com/rust-analyzer/rust-analyzer/blob/4f91478e50dc5c2a87235e9be8bd91e3f62de4b4/crates/ide/src/completion/complete_trait_impl.rs#L109
Co-authored-by: oxalica <[email protected]>
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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 <[email protected]>
|
| | |/ /
| |/| | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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 <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |/ / /
|/| | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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 <[email protected]>
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| | | | | |
| \ \ \ | |
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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 <[email protected]>
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | |/ /
| | |/| | |
|
| | | | | |
|
|\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
5970: Use better heuristics for replacement text when removing dbg! r=jonas-schievink a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5911
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | | | |
|
| |/ / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
5969: Propose module name completion options r=jonas-schievink a=SomeoneToIgnore
<img width="539" alt="image" src="https://user-images.githubusercontent.com/2690773/92663009-cb0aec00-f308-11ea-9ef5-1faa91518031.png">
Currently traverses the whole file set every time we try to complete the module, as discussed in https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/mod.3C.7C.3E.20completion
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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 <[email protected]>
|
| | | | | |
|
| | |/ /
| |/| | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
![изображение](https://user-images.githubusercontent.com/12111581/92319594-b71e6c00-f022-11ea-94c1-f412905269dd.png)
Co-authored-by: Igor Aleksanov <[email protected]>
|
| |/ / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|