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>
- 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.
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>
Allow trait autocompletions for unimplemented associated fn's, types,
and consts without using explicit keywords before hand (fn, type,
const).
The sequel to #3108.
Note that `detail` was replced with `function_signature` to avoid
calling `from` on FunctionSignature twice.
I didn't add new tests because the current ones seem enough.
3384: fix#2377 super::super::* r=flodiebold a=JoshMcguigan
Thanks @matklad for the detailed explanation on #2377. I believe this fixes it.
One thing I'm not sure about is you said the fix would involve changing `crates/ra_hir_def/src/path/lower/lower.rs`, but I only changed `crates/ra_hir_def/src/path/lower/lower_use.rs`. I'm not sure what kind of test code I'd have to write to expose the issue in `lower.rs`, but I'd be happy to add it if you are able to provide additional guidance.
closes#2377
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3366: Simpilfy original_range logic r=matklad a=edwin0cheng
This PR fixed another [bug](https://github.com/rust-analyzer/rust-analyzer/issues/3000#issuecomment-592474844) which incorrectly map the wrong range of `punct` in macro_call and simplify the logic a little bit by introducing an `ascend_call_token` function.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3285: Handle trivia in Structural Search and Replace r=matklad a=adamrk
Addresses the second point of https://github.com/rust-analyzer/rust-analyzer/issues/3186.
Structural search and replace will now match code that has varies from the pattern in whitespace or comments.
One issue is that it's not clear where comments in the matched code should go in the replacement. With this change they're just tacked on at the end, which can cause some unexpected moving of comments (see the last test example).
Co-authored-by: adamrk <ark.email@gmail.com>
This introduces the new type -- Semantics.
Semantics maps SyntaxNodes to various semantic info, such as type,
name resolution or macro expansions.
To do so, Semantics maintains a HashMap which maps every node it saw
to the file from which the node originated. This is enough to get all
the necessary hir bits just from syntax.
3260: Refactor how builtins are resolved r=matklad a=flodiebold
This fixes autocompletion suggesting e.g. `self::usize`. (I thought we had a bug for that, but I didn't find it.)
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
3228: Use proper range for hover on macro arguments r=matklad a=edwin0cheng
This PR use `original_range` to remap the range of found syntax node in `hover` and thus it should return the proper text range now.
fixed#3000fixed#3135
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3099: Init implementation of structural search replace r=matklad a=mikhail-m1
next steps:
* ignore space and other minor difference
* add support to ra_cli
* call rust parser to check pattern
* documentation
original issue #2267
Co-authored-by: Mikhail Modin <mikhailm1@gmail.com>
3108: Magic Completion for `impl Trait for` Associated Items r=matklad a=kdelorey
# Summary
This PR adds a set of magic completions to auto complete associated trait items (functions/consts/types).
## Notes
Since the assist and completion share the same logic when figuring out the associated items that are missing, a shared utility was created in the `ra_assists::utils` module.
Resolves#1046
As this is my first PR to the rust-analyzer project, I'm new to the codebase, feedback welcomed!
Co-authored-by: Kevin DeLorey <2295721+kdelorey@users.noreply.github.com>
3153: When a single test is run, do not run others with overlapping names r=matklad a=SomeoneToIgnore
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
The extra allocation for message should not matter here at all, but
using a static string is just as ergonomic, if not more, and there's
no reason to write deliberately slow code
2887: Initial auto import action implementation r=matklad a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/2180
Adds an auto import action implementation.
This implementation is not ideal and has a few limitations:
* The import search functionality should be moved into a separate crate accessible from ra_assists.
This requires a lot of changes and a preliminary design.
Currently the functionality is provided as a trait impl, more on that here: https://github.com/rust-analyzer/rust-analyzer/issues/2180#issuecomment-575690942
* Due to the design desicion from the previous item, no doctests are run for the new aciton (look for a new FIXME in the PR)
* For the same reason, I have to create the mock trait implementaion to test the assist
* Ideally, I think we should have this feature as a diagnostics (that detects an absense of an import) that has a corresponding quickfix action that gets evaluated on demand.
Curretly we perform the import search every time we resolve the import which looks suboptimal.
This requires `classify_name_ref` to be moved from ra_ide, so not done currently.
A few improvements to the imports mechanism to be considered later:
* Constants like `ra_syntax::SyntaxKind::NAME` are not imported, because they are not present in the database
* Method usages are not imported, they are found in the database, but `find_use_path` does not return any import paths for them
* Some import paths returned by the `find_use_path` method end up in `core::` or `alloc::` instead of `std:`, for example: `core::fmt::Debug` instead of `std::fmt::Debug`.
This is not an error techically, but still looks weird.
* No detection of cases where a trait should be imported in order to be able to call a method
* Improve `auto_import_text_edit` functionality: refactor it and move away from the place it is now, add better logic for merging the new import with already existing imports
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
2899: Provide more runners for potential tests r=matklad a=SomeoneToIgnore
Based on the https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Runners.20for.20custom.20test.20annotations discussion.
Adds a test runner for every method that has an annotation that contains `test` word in it, allowing to run tests annotated with custom testing annotations such as `#[tokio::test]`, `#[test_case(...)]` and others at costs of potentially emitting some false-positives.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
2837: Accidentally quadratic r=matklad a=matklad
Our syntax highlighting is accdentally quadratic. Current state of the PR fixes it in a pretty crude way, looks like for the proper fix we need to redo how source-analyzer works.
**NB:** don't be scared by diff stats, that's mostly a test-data file
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2772: Actually test references r=kjeremy a=kjeremy
This will be a little more work when `ReferenceSearchResults` change but I think it's easier to maintain in the end. It also follows a similar pattern to navigation targets and call hierarchy.
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
Let's be always explicit whether we create a library (i.e., an immutable
dependency) or a local `SourceRoot`, since it can have a large impact on
the validation performance in salsa. (we found it the hard way recently,
where the `Default` instance made it quite tricky to spot a bug)
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
When processing a change with added libraries, we used
`Default::default` for `SourceRoot` which sets `is_library` to false.
Since we use `is_library` to decide whether to use low or high
durability, I believe that this caused us to mark many library
dependencies as having low durability and thus increased the size of the
graph that salsa needed to verify on every change.
Based on my initial tests this speeds up the `CrateDefMapQuery` on
rust-analyzer from about ~64ms to ~14ms and reduces the number of
validations for the query from over 60k to about 7k.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
This change:
- introduces `compute_crate_def_map` query and renames
`CrateDefMap::crate_def_map_query` for consistency,
- annotates `crate_def_map` as `salsa::transparent` and adds a
top-level `crate_def_map` wrapper function around that starts the
profiler and immediately calls into `compute_crate_def_map` query.
This allows us to better understand where we spent the time, in
particular, how much is spent in the recomputaiton and how much in
salsa.
Example output (where we don't actually re-compute anything, but the
query still takes a non-trivial amount of time):
```
211ms - handle_inlay_hints
150ms - get_inlay_hints
150ms - SourceAnalyzer::new
65ms - def_with_body_from_child_node
65ms - analyze_container
65ms - analyze_container
65ms - Module::from_definition
65ms - Module::from_file
65ms - crate_def_map
1ms - parse_macro_query (6 calls)
0ms - raw_items_query (1 calls)
64ms - ???
```
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
2667: Visibility r=matklad a=flodiebold
This adds the infrastructure for handling visibility (for fields and methods, not in name resolution) in the HIR and code model, and as a first application hides struct fields from completions if they're not visible from the current module. (We might want to relax this again later, but I think it's ok for now?)
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
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>
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>
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.
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>
SourceAnalyzer didn't work properly within expression macro expansions because
it didn't find the enclosing function. Fix this by going up the expansion chain
to find ancestors. This makes the test work, but apparently in real usage it's
still not working.
