2311: See through Macros for SignatureHelp r=matklad a=kjeremy
Note: we meed to skip the trivia filter to make sure that
`covers!(call_info_bad_offset)` succeeds otherwise we exit call_info
too early.
Also the test doesn't pass: `FnCallNode::with_node` always detects
a MacroCall which is obviously wrong.
Fixes#2310
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
Note: we meed to skip the trivia filter to make sure that
`covers!(call_info_bad_offset)` succeeds otherwise we exit call_info
too early.
Also the test doesn't pass: `FnCallNode::with_node` always detects
a MacroCall.
2562: Fix NavigationTarget ranges r=matklad a=edwin0cheng
Fix the issue described in https://github.com/rust-analyzer/rust-analyzer/pull/2544#issuecomment-565572553
This PR change the order for finding `full_range` of `focus_range` in following orders:
1. map both ranges to macro_call
2. map focus range to a token inside macro call, and full range to the whole of macro call
3. map both ranges to the whole of macro call
And fix the corresponding tests and make these tests easily to follow.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
When calling a function, argument-position impl Trait is transparent; same for
return-position impl Trait when inside the function. So in these cases, we need
to represent that type not by `Ty::Opaque`, but by a type variable that can be
unified with whatever flows into there.
2559: Add some granularity to syntax highlighting. r=matklad a=omerbenamram
Hi,
I wanted to start using `rust-analyzer` a bit more frequently - one of the main blockers for me so far was the highlighting.
I just discovered it's possible to override the default colors with `ralsp.<something>` setting without waiting for #2061!
However, the current implementation was lumping a bunch of different tokens into `type` and `literal`.
The golden standard IMO is what Clion is currently doing (and is my current daily driver for rust).
Clion allows users to control the coloring for specific literal kinds, and the default is to distinguish between them (numerics get a different color from strings, and special colors for bytestrings).
I've also splitted the builtin types, which are also allowed to be highlighted speratly.
My goal is to match the default experience I'm getting with clion.
The only blockers now I think is that `rust-analyzer` doesn't corrently infer types in some situations, so the highlighting information is incorrect in those cases.
This is what it looks like so far (with colors overriden to match clion's theme):
If there are any other changes you feel is necessary let me know.
I did leave the default colors to match the current behavior, since I'm not familiar with the colors for this theme, I added some random (different) colors in the test to check that it indeed was working.
Co-authored-by: Omer Ben-Amram <omerbenamram@gmail.com>
2552: fix goto definition when inbetween tokens r=matklad a=succcubbus
fixes both goto_definition and goto_type_definition.
before, when running goto between some non-trivia token and an
identifier, goto would be attempted for the non-trivia token.
but this does not make sense for e.g. L_PAREN or COLONCOLON only for
IDENTs.
this resulted in goto actions not working when running them on the first
character of some identifier e.g. for `module::<|>method()` or
`method(<|>parameter)`.
now only IDENTs will be searched for in goto actions, though i'm not sure
if this is correct or if goto should also work for some other token types.
Co-authored-by: succcubbus <16743652+succcubbus@users.noreply.github.com>
2550: Infer - and ! using std::ops::{Neg, Not} r=flodiebold a=kiljacken
Found some low hanging fruit while taking a cursory look at index inferring.
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
fixes both goto_definition and goto_type_definition.
before, when running goto between some non-trivia token and an
identifier, goto would be attempted for the non-trivia token.
but this does not make sense for e.g. L_PAREN or COLONCOLON only for
IDENTs. now only IDENTs will be searched for in goto actions.
2544: Map first and last tokens in original_range r=matklad a=edwin0cheng
This PR try to fix the first part of the `original_range` : Try to map the first token and last token of a `SyntaxNode` , If success, return the union range of mapped tokens.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Tuple in type annotation expands correctly;
Expansion will prefer the following delimiter when possible.
New regression tests added to verify the consistency between tuple expansion in type annotation and tuple expansion in rvalue.
2500: Fix format_args expansion & go to definition r=matklad a=flodiebold
The expansion of format_args wasn't yet correct enough to type-check. Also make macros in statement position expand to expressions for now, since it's not handled correctly in HIR lowering yet. This finally fixes go to definition within print macros, I think 🙂
2505: Remove more dead code r=matklad a=matklad
2506: Remove one more Ty r=matklad a=matklad
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2501: Fix coercion from &Foo to an inference variable in a reference r=matklad a=flodiebold
We didn't try to unify within the reference, but we should.
2502: Delay legacy macro expansion r=matklad a=edwin0cheng
This PR make the following changes:
* Delay legacy macro expansion such that we concentrated all item collecting macro expansion in one place.
* Add `MacroDirective` to replace 3-tuples
* After this refactoring, no macro is expanded recursively, hence we can remove the `MacroStackMonitor` and we handle the expansion limit by the fix-point loop count.
2503: Code: check whether the LSP binary is in PATH r=matklad a=lnicola
I'm not really sure about the TS changes. I just made a couple of functions async and it seems to work.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2466: Handle partial resolve cases r=matklad a=edwin0cheng
Another try to fix#2443 :
We resolve all imports every time in `DefCollector::collect` loop even it is resolved previously.
This is because other unresolved imports and macros will bring in another `PerNs`, so we can only assume that it has been partially resolved.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
