The `-` turned into a `+` during a refactoring.
The original issue was caused by `Read` resolving wrongly to a trait without
type parameters instead of a struct with one parameter; this only fixes the
crash, not the wrong resolution.
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>
In particular:
- Use strict inequality for comparisons, since that's what the filter
syntax supports.
- Convert to millis for comparisons, since that's the unit used both
for the filter and when printing.
Now something like `RA_PROFILE='*>0'` will only print things that took
at least 1ms (when rounded to millis).
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
2681: cargo-watcher: Resolve macro call site in more cases r=matklad a=kiljacken
This resolves the actual macro call site in a few more cases, f.x. when a macro invokes `compile_error!` (I'm looking at you `ra_hir_def::path::__path`).
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
2668: In-server cargo check watching r=matklad a=kiljacken
Opening a draft now so people can follow the progress, and comment if they spot something stupid.
Things that need doing:
- [x] Running cargo check on save
- [x] Pipe through configuration options from client
- [x] Tests for parsing behavior
- [x] Remove existing cargo watch support from VSCode extension
- [x] Progress notification in VSCode extension using LSP 3.15 `$/progress` notification
- [ ] ~~Rework ra-ide diagnostics to support secondary messages~~
- [ ] ~~Make cargo-check watcher use ra-ide diagnostics~~
~~I'd love some input on whether to try to keep the status bar progress thingy for VSCode? It will require some plumbing, and maintaining yet another rust-analyzer specific LSP notification, which I'm not sure we want to.~~
Fixes#1894
Co-authored-by: Emil Lauridsen <mine809@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>
2657: Omit closure parameters in closure type display strings r=flodiebold a=SomeoneToIgnore
Part of https://github.com/rust-analyzer/rust-analyzer/issues/1946
I wonder, should we display the the closure trait (Fn/FnMut/FnOnce) in inlay hints instead of `|...|` at all?
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
2658: Only add features flags if non-empty r=matklad a=edwin0cheng
This prevent error when disabled `all-features` in a cargo workspace, because of `--features is not allowed in the root of a virtual workspace` when running `cargo metadata`.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2661: Implement infer await from async function r=flodiebold a=edwin0cheng
This PR is my attempt for trying to add support for infer `.await` expression from an `async` function, by desugaring its return type to `Impl Future<Output=RetType>`.
Note that I don't know it is supposed to desugaring it in that phase, if it is not suitable in current design, just feel free to reject it :)
r=@flodiebold
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2636: Chalk update and refactoring r=flodiebold a=flodiebold
This updates the Chalk integration to https://github.com/rust-lang/chalk/pull/311, which will presumably get merged soon, and refactors it some more, most notably introducing our own `TypeFamily` instead of reusing `ChalkIr`. It's still mostly the same as `ChalkIr` though, except for using Salsa `InternId`s directly.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
It's not very different, except we can directly use Salsa IDs instead of casting
them. This means we need to refactor the handling of errors to get rid of
UNKNOWN_TRAIT though.
2641: Parse const generics r=matklad a=roblabla
Adds very primitive support for parsing const generics (`const IDENT: TY`) so that rust-analyzer stops complaining about the syntax being invalid.
Fixes#1574Fixes#2281
Co-authored-by: roblabla <unfiltered@roblab.la>
2629: Remove imports from hir r=matklad a=matklad
We only used them to avoid self-confirming completions (`use self::foo`), but that can be handled more locally.
bors r+
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2628: Add macro 2.0 support in parser r=matklad a=edwin0cheng
This PR added a new syntax kind : `MACRO_DEF` and a keyword `MACRO_KW`
there are two syntax for declarative macro 2.0 :
1. Normal : `macro m { ($i:ident) => {} }` , which handle similar to legacy one.
2. Call like: `macro m($i:ident) {}`, it produces a single token tree which have two child token trees : `($i:ident)` and `{}`
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2623: Add support macros in impl blocks r=matklad a=edwin0cheng
This PR add support for macros in impl blocks, which reuse `Expander` for macro expansion.
see also: #2459
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2614: Clippy cleanup r=matklad a=kjeremy
Just a few tweaks from the latest clippy. There are a lot more but we should probably tweak our settings.
Co-authored-by: kjeremy <kjeremy@gmail.com>
2592: Add std::ops::Index support for infering r=edwin0cheng a=edwin0cheng
see also #2534
Seem like this can't fix#2534 for this case:
```rust
fn foo3(bar: [usize; 2]) {
let baz = bar[1]; // <--- baz is still unknown ?
println!("{}", baz);
}
```
Co-authored-by: Edwin Cheng <edwin0cheng@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>
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>
2489: Implement `format_args` r=flodiebold a=flodiebold
This fixes a huge amount of type mismatches (because every format call was a type mismatch so far); I also hoped to get go to def working within `format!` etc., and the test says it should, but in practice it still doesn't seem to...
Also remove the `len` parameter from `Name::new_inline_ascii`, which I'm assuming was only there because of `const fn` limitations?
cc @edwin0cheng
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2484: DynMap r=matklad a=matklad
Implement a `DynMap` a semi-dynamic, semi-static map, which helps to thread heterogeneously typed info in a uniform way. Totally inspired by df3bee3038/compiler/frontend/src/org/jetbrains/kotlin/resolve/BindingContext.java.
@flodiebold wdyt? Seems like a potentially useful pattern for various source-map-like things.
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.
If we are expecting a `&Foo` and get a `&something`, when checking the
`something`, we are *expecting* a `Foo`, but we shouldn't try to unify whatever
we get with that expectation, because it could actually be a `&Foo`, and `&&Foo`
coerces to `&Foo`. So this fixes quite a few false type mismatches.
2479: Add expansion infrastructure for derive macros r=matklad a=flodiebold
I thought I'd experiment a bit with attribute macro/derive expansion, and here's what I've got so far. It has dummy implementations of the Copy / Clone derives, to show that the approach works; it doesn't add any attribute macro support, but I think that fits into the architecture.
Basically, during raw item collection, we look at the attributes and generate macro calls for them if necessary. Currently I only do this for derives, and just add the derive macro calls as separate calls next to the item. I think for derives, it's important that they don't obscure the actual item, since they can't actually change it (e.g. sending the item token tree through macro expansion unnecessarily might make completion within it more complicated).
Attribute macros would have to be recognized at that stage and replace the item (i.e., the raw item collector will just emit an attribute macro call, and not the item). I think when we implement this, we should try to recognize known inert attributes, so that we don't do macro expansion unnecessarily; anything that isn't known needs to be treated as a possible attribute macro call (since the raw item collector can't resolve the macro yet).
There's basically no name resolution for attribute macros implemented, I just hardcoded the built-in derives. In the future, the built-ins should work within the normal name resolution infrastructure; the problem there is that the builtin stubs in `std` use macros 2.0, which we don't support yet (and adding support is outside the scope of this).
One aspect that I don't really have a solution for, but I don't know how important it is, is removing the attribute itself from its input. I'm pretty sure rustc leaves out the attribute macro from the input, but to do that, we'd have to create a completely new syntax node. I guess we could do it when / after converting to a token tree.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
The stand-alone `unify` requires that the type doesn't contain any type
variables. So we can't share the code here for now (without more refactoring)...
2465: Extract built-in trait implementations to separate module r=matklad a=flodiebold
This untangles the builtin logic from the Chalk translation.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2018: assists: add assist for custom implementation for derived trait r=matklad a=paulolieuthier
Please, tell me if something could be more idiomatic or efficient.
Fixes#1256.
Co-authored-by: Paulo Lieuthier <paulolieuthier@gmail.com>
2455: Add BuiltinShadowMode r=flodiebold a=edwin0cheng
This PR try to fix#1905 by introduce an `BuiltinShadowMode` in name resolving functions.
cc @flodiebold
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2451: Use env_logger instead of flexi_logger r=matklad a=AlexanderEkdahl
This fixes https://github.com/rust-analyzer/rust-analyzer/issues/2335
- By default only `error` will be printed. From what I can tell this matches the current behaviour. Configured through `RUST_LOG`.
- I looked through the optional dependencies for `env_logger`and I have only enabled `human_time`. Without this feature no timestamp will be shown for log messages.
- `RA_LOG_DIR` feature is removed
This PR adds 2 new dependencies(`env_logger` and `human_time`) and removes 6 dependencies.
Co-authored-by: Alexander Ekdahl <alexander@ekdahl.io>
2418: Hide MacroCallLoc outside hir_expand r=matklad a=edwin0cheng
This PR refactor `MacroCallLoc` such that it be hided to become implementation details of hir_expand.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Although structs and unions have the same syntax and differ only in
the keyword, re-using the single syntax node for both of them leads to
confusion in practice, and propagates further down the hir in an
upleasent way.
Moreover, static and consts also share syntax, but we use different
nodes for them.
2388: Show missing struct fields in the error message r=matklad a=Frizi
This provides the most interesting information about the "missing structure fields" error directly to the user.
Co-authored-by: Frizi <frizi09@gmail.com>
2362: Expand compile_error! r=edwin0cheng a=kjeremy
Does not validate that the input is a string literal. I thought that I could `match_ast!` against the `macro_args` but that did not work. Even if it had I am not sure which error would be appropriate.
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
2392: Fix panic during the expansion of `column!` r=edwin0cheng a=marcogroppo
Fixes#2379. Well, this isn't the "proper" fix but it doesn't hurt, IMHO.
The problem is that `to_col_number`, called by `column_expand`, receives a position number that isn't included in the text range of the file. My (very limited) understanding is that the text is the one of the original file, while `pos` is relative to something else, probably the text of the macro. Notice that in this case the `column!` expansion seems to be triggered by `assert_eq!`, so we're in the middle of another expansion. This PR simply avoids the panic by checking the length of the text.
r? @edwin0cheng
Co-authored-by: Marco Groppo <marco.groppo@gmail.com>
2396: Switch to variant-granularity field type inference r=flodiebold a=matklad
r? @flodiebold
Previously, we had a `ty` query for each field. This PR switcthes to a query per struct, which returns an `ArenaMap` with `Ty`s.
I don't know which approach is better. What is bugging me about the original approach is that, if we do all queries on the "leaf" defs, in practice we get a ton of queries which repeatedly reach into the parent definition to compute module, resolver, etc. This *seems* wasteful (but I don't think this is really what causes any perf problems for us).
At the same time, I've been looking at Kotlin, and they seem to use the general pattern of analyzing the *parent* definition, and storing info about children into a `BindingContext`.
I don't really which way is preferable. I think I want to try this approach, where query granularity generally mirrors the data granularity. The primary motivation for me here is probably just hope that we can avoid adding a ton of helpers to a `StructField`, and maybe in general avoid the need to switch to a global `StructField`, using `LocalStructFieldId` most of the time internally.
For external API (ie, for `ra_ide_api`), I think we should continue with fine-grained `StructField::ty` approach, which internally fetches the table for the whole struct and indexes into it.
In terms of actual memory savings, the results are as follows:
```
This PR:
142kb FieldTypesQuery (deps)
38kb FieldTypesQuery
Status Quo:
208kb TypeForFieldQuery (deps)
18kb TypeForFieldQuery
```
Note how the table itself occupies more than twice as much space! I don't have an explanation for this: a plausible hypothesis is that single-field structs are very common and for them the table is a pessimisation.
THere's noticiable wallclock time difference.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2381: Add proc-macro crate type handling r=JasperDeSutter a=JasperDeSutter
Resolves the libproc_macro crate in crates that are the proc-macro type.
This doesn't seem the ideal implementation though, since the compiler still requires you to write `extern crate proc_macro;` (even in 2018 edition).
Co-authored-by: JasperDeSutter <jasper.desutter@gmail.com>
2383: Add alloc to the crate graph r=matklad a=marcogroppo
`alloc` has been added to the crate graph.
Completions work, but they are available even when the user has **not** declared an `extern crate alloc`. Is this the correct approach?
Fixes#2376.
Co-authored-by: Marco Groppo <marco.groppo@gmail.com>
2365: Make expand-macro more flexible r=matklad a=edwin0cheng
Due to lack of implementation or other types of errors, some macros do not expand correctly in the current situation. The PR attempts to make `expand-macro` more flexible in error situations by ignoring internal failed macro expansion.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2343: implement assist invert_if r=matklad a=bravomikekilo
fix [issue 2219 invert if condition](https://github.com/rust-analyzer/rust-analyzer/issues/2219)
I put the assist cursor range to `if` of the if expression, because both condition and body will be replaced. Is there any way to replace them without cover the cursor position?
@matklad
Co-authored-by: bravomikekilo <bmk1221@126.com>
2348: Add support for stringify! builtin macro r=matklad a=piotr-szpetkowski
Refs #2212
First time ever contributing here, hopefully it's ok.
2352: Move TypeAlias to hir_def r=matklad a=matklad
Co-authored-by: Piotr Szpetkowski <piotr.szpetkowski@pyquest.space>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
The current system with AstIds has two primaraly drawbacks:
* It is possible to manufacture IDs out of thin air.
For example, it's possible to create IDs for items which are not
considered in CrateDefMap due to cfg. Or it is possible to mixup
structs and unions, because they share ID space.
* Getting the ID of a parent requires a secondary index.
Instead, the plan is to pursue the more traditional approach, where
each items stores the id of the parent declaration. This makes
`FromSource` more awkward, but also more correct: now, to get from an
AST to HIR, we first do this recursively for the parent item, and the
just search the children of the parent for the matching def
This commit implements a general truncation framework for HirFormatter
that keeps track of how much has been output so far. This information
can then be used to perform truncation inside the language server,
instead of relying on the client.
Initial support is implemented for truncating types hints using the
maxInlayHintLength server config option. The existing solution in the
VSCode extension has been removed in favor of letting the server
truncate type hints.
2307: Support hover through macro r=matklad a=kjeremy
Allows hover to work through macros like `match_ast!`.
Co-authored-by: kjeremy <kjeremy@gmail.com>
We need to be more careful now when substituting bound variables (previously, we
didn't have anything that used bound variables except Chalk, so it was not a
problem).
This is obviously quite ad-hoc; Chalk has more infrastructure for handling this
in a principled way, which we maybe should adopt.
2252: Fix parsing of "postfix" range expressions. r=matklad a=goffrie
Right now they are handled in `postfix_dot_expr`, but that doesn't allow it to
correctly handle precedence. Integrate it more tightly with the Pratt parser
instead.
Also includes a drive-by fix for parsing `match .. {}`.
Fixes#2242.
Co-authored-by: Geoffry Song <goffrie@gmail.com>
Right now they are handled in `postfix_dot_expr`, but that doesn't allow it to
correctly handle precedence. Integrate it more tightly with the Pratt parser
instead.
Also includes a drive-by fix for parsing `match .. {}`.
Fixes#2242.
2165: ra_assists: Add add_new assist r=matklad a=rep-nop
Adds a new assist to autogenerate a new fn based on the selected struct, excluding tuple structs and unions. The fn will inherit the same visibility as the struct and the assist will attempt to reuse any existing impl blocks that exist at the same level of struct.
Not marking this as closing #1644 since there's a part 2 of adding autocompletion for when someone starts typing `[pub ]fn new(...`
Co-authored-by: Wesley Norris <repnop@outlook.com>
2249: Cleanup hover r=matklad a=kjeremy
Take advantage of classify_name to consolidate multiple hover paths. This isn't quite as clean as I want it to be (`no_fallback` bool is wonky). There's a relationship between `HoverResult` being empty and the range that is a little warty.
Also I noticed that HoverResults are always marked as exact and have been for quite a while... maybe that should be removed in another PR.
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
2217: Implement FromStr for enum Edition r=matklad a=clemarescx
Just did this as I came across the comment in the code asking for implementing `std::str::FromStr` for `input::Edition`.
Not sure what was meant by "proper error handling" though, `panic!` with a descriptive message might not be it 😅
Co-authored-by: Metabaron <metabaron@tuta.io>
2200: Add variables to HIR r=matklad a=matklad
Introduce a `hir::Variable`, which should cover locals, parameters and `self`. Unlike `PatId`, variable knows it's owner so it is self-contained, and should be more convenient to use from `ra_ide_api`.
The goal here is to hide more details about `Body` from hir, which should make it easier to move `Body` into `hir_def`. I don't think that `ra_ide_api` intrracts with bodies directly at the moment anyway, but the glue layer is based basically on `ast::BindPat`, which seems pretty brittle.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2205: Implement bulitin line! macro r=matklad a=edwin0cheng
This PR implements bulitin macro `line!` and add basic infra-structure for other bulitin macros:
1. Extend `MacroDefId` to support builtin macros
2. Add a `quote!` macro for simple quasi quoting.
Note that for support others builtin macros, eager macro expansion have to be supported first, this PR not try to handle it. :)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
This removes the special casing for the "core" prelude.
Whenever a later dependency also exports a prelude, it will replace
the formerly imported prelude. The utilized prelude then depends
purely on import order.
This adds support for completion and goto definition of
types defined within the "core" crate. The core crate is
added as a dependency to each crate in the project.
The core crate exported it's own prelude. This caused
now all crates to inherit the core crates prelude instead
of the std crates. In order to avoid the problem the
prelude resolution has been changed to overwrite
an already resolved prelude if this was set to a crate
named core - in order to pick a better prelude like std.
Fixes#2199
Adds a new assist to autogenerate a new fn based on the selected struct,
excluding tuple structs and unions. The fn will inherit the same
visibility as the struct and the assist will attempt to reuse any
existing impl blocks that exist at the same level of struct.
2169: MBE: Mapping spans for goto definition r=matklad a=edwin0cheng
Currently, go to definition gives the wrong span in MBE. This PR implement a mapping mechanism to fix it and it could be used for future MBE hygiene implementation.
The basic idea of the mapping is:
1. When expanding the macro, generated 2 `TokenMap` which maps the macro args and macro defs between tokens and input text-ranges.
2. Before converting generated `TokenTree` to `SyntaxNode`, generated a `ExpandedRangeMap` which is a mapping between token and output text-ranges.
3. Using these 3 mappings to construct an `ExpansionInfo` which can map between input text ranges and output text ranges.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Removes nodrop and extra arrayvec
We have an extra crossbeam-queue and crossbeam-utils left but those should
drop once rayon accepts https://github.com/rayon-rs/rayon/pull/704
2179: Use HirDatabase to compute `is_deprecated` r=matklad a=martskins
This PR fixes#2167 by introducing `attributes_query` and adding `fn attrs(&self, def: crate::AttrDef) -> Option<Arc<[Attr]>>;` to the `DefDatabase` trait.
I'm a little concerned about the two spots in `attributes_query` where code is repeated, but I couldn't figure out a way to avoid that, so.. I welcome suggestions 😄
Co-authored-by: Martin Asquino <martin.asquino@gmail.com>
2173: MBE: Add TokenId shift in macro_rules r=matklad a=edwin0cheng
As discussed in #2169 , for fixing duplication TokenId during expansion :
> What we can do here is to re-number the tokens during expansion. Specifically:
> * when we create macro_rules, we note the highest id of the token we have as shift>
> * when we expand macro rules, if we need to output a token from definition, we just re-use its id
> * if we need to output a token from the argument, we increase its id by shift (so it's guaranteed to not to collide with anything from the definition)
> * finally, when we have a HirFileId of the expansion, we can look up the original value of shift and classify node to the arg/def by comparing it's id with shift.
>
This PR implement first 3 points of above solution.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2149: Handle IfLet in convert_to_guarded_return. r=matklad a=krk
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/2124
I could not move the cursor position out of `let`:
`le<|>t` vs `let<|>`.
Also, please suggest extra test cases.
Co-authored-by: krk <keremkat@gmail.com>
2160: Set `deprecated` field on `CompletionItem`s r=matklad a=martskins
This PR aims to address #2042 by setting the deprecated field for completion items.
The setting the tags field for LSP 3.15 part still needs fixing, but that one is blocked due to lsp-types not being up to date with 3.15 yet.
Co-authored-by: Martin Asquino <martin.asquino@gmail.com>
