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.
