| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This adds documentation for the newly added function. It might be a bit too
detailed, but I like it that way :)
|
|
|
|
|
|
| |
This is done by adding a `ret_type` method to `hir::Function`.
I followed `assoc_fn_params` convention by creating a new `RetType` type,
that contains the actual return type accessible via a `ty` method.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7068: Add VSCode command to view the hir of a function body r=theotherphil a=theotherphil
Will fix https://github.com/rust-analyzer/rust-analyzer/issues/7061. Very rough initial version just to work out where I needed to wire everything up.
@matklad would you be happy merging a hir visualiser of some kind? If so, do you have any thoughts on what you'd like it show, and how?
I've spent very little time on this thus far, so I'm fine with throwing away the contents of this PR, but I want to avoid taking the time to make this more polished/interactive/useful only to discover that no-one else has any interest in this functionality.
![image](https://user-images.githubusercontent.com/1974256/103236081-bb58f700-493b-11eb-9d12-55ae1b870f8f.png)
Co-authored-by: Phil Ellison <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
special cased
In #6901 some special case handling for proc-macros was introduced to
prevent panicing as they have no AST. Now the new HasSource::source
method is used that returns an option.
Generally this was a pretty trivial change, the only thing of much
interest is that `hir::MacroDef` now implements `TryToNav` not `ToNav`
as this allows us to handle `HasSource::source` now returning an option.
|
| | |
|
| |
| |
| |
| | |
To start migrating HasSource::source to return an Option.
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
7021: Track labels in the HIR r=matklad a=Veykril
Groundwork for #6966
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
6964: Add full pattern completions for Struct and Variant patterns r=matklad a=Veykril
Just gonna call it full pattern completion as pattern completion is already implemented in a sense by showing idents in pattern position. What this does is basically complete struct and variant patterns where applicable(function params, let statements and refutable pattern locations).
This does not replace just completing the corresponding idents of the structs and variants, instead two completions are shown for these, a completion for the ident itself and a completion for the pattern(if the pattern make sense to be used that is). I figured in some cases one would rather type out the pattern manually if it has a lot of fields but you only care about one since this completion would cause one more work in the end since you would have to delete all the extra matched fields again.
These completions are tagged as `CompletionKind::Snippet`, not sure if that is the right one here.
<details>
<summary>some gifs</summary>
![dx2lxgzhj3](https://user-images.githubusercontent.com/3757771/102719967-6987ef80-42f1-11eb-8ae0-8aff53777860.gif)
![EP2E7sJLkB](https://user-images.githubusercontent.com/3757771/102785777-c7264580-439e-11eb-8a64-f142e19fb65b.gif)
![JMNHHWknr9](https://user-images.githubusercontent.com/3757771/102785796-d1e0da80-439e-11eb-934b-218ada31b51c.gif)
</details>
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
6921: Higher-ranked trait bounds for where clauses r=flodiebold a=Veykril
There is a slight problem with this which is also noted in a FIXME now but `LifetimeParameters` of these ForLifetime where clauses allocate the lifetimes in the corresponding arena as if they were lifetimes of the item itself and not just the clause they belong to. I wasn't entirely sure what I could do about this but given nothing really uses lifetimes like that currently I figured it might be fine? Open to suggestions for that problem.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6901: Temp fixes panic caused by no ast for proc-macro r=maklad a=edwin0cheng
There are some panic when hover/goto definition for proc-macro. It is because in current design, we don't have `ast-node` for proc-macro and then it trigger [this](https://github.com/rust-analyzer/rust-analyzer/blob/479d1f7eec22c3564867223e2093f14774092528/crates/hir/src/has_source.rs#L116) line to panic.
This PR is a temp fix for all of these similar to https://github.com/rust-analyzer/rust-analyzer/blob/bd4c352831662762ee7a66da77ec9adf623b0a0a/crates/completion/src/render/macro_.rs#L42
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| | |
We used to have `Def` suffix for all symbols, but we moved off from
that. `FunctionDef` isn't better than `Function`. Looks like we've
forgot to change `Impl` though!
|
| | |
|
|/
|
|
| |
Refactors builtin derive support to go through proper name resolution
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
6251: Semantic Highlight: Add Callable modifier for variables r=matklad a=GrayJack
This PR added the `HighlightModifier::Callable` variant and assigned it to variables and parameters that are fn pointers, closures and implements FnOnce trait.
This allows to colorize these variables/parameters when used in call expression.
6310: Rewrite algo::diff to support insertion and deletion r=matklad a=Veykril
This in turn also makes `algo::diff` generate finer diffs(maybe even minimal diffs?) as insertions and deletions aren't always represented as as replacements of parent nodes now.
Required for #6287 to go on.
Co-authored-by: GrayJack <[email protected]>
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | |
|
| |/
|/| |
|
| | |
|
|/
|
|
|
|
|
|
| |
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).
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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:
![case_quick_fix](https://user-images.githubusercontent.com/12111581/95008475-e07ee780-0622-11eb-9978-62a9ea0e7782.gif)
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 <[email protected]>
Co-authored-by: Benjamin Coenen <[email protected]>
|
| | | |
|