Merge #2430

2430: rename ra_ide_api -> ra_ide r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Reformat

rename ra_ide_api -> ra_ide

Rename module_id -> local_id

Merge #2429

2429: Move type inference to a separate crate r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

prune deps

Move Ty

Decouple

Merge #2428

2428: Remove TypableDef r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Remove TypableDef

Cleanup imports

Use Id for variats

More decoupling

Decouple more

Merge #2427

2427: Decouple r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Decouple

Merge #2426

2426: Decouple r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Decouple

Cleanup imports

Merge #2425

2425: Decouple r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Decouple

Decouple

Merge #2424

2424: Crate -> CrateId r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Crate -> CrateId

Merge #2422

2422: Use a simple progress bar instead of indicatif r=maklad a=edwin0cheng


Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>

Fill all last text to space and return the cursor

Remove progress bar and add a true counter

Remove commented code

Use a simple progress bar instead of indicatif

Merge #2421

2421: Cleanup r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Cleanup

Decouple

Merge #2420

2420: Remove last traces of adt from Ty r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Merge #2418

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>

Remove last traces of adt from Ty

More precise NameKind::Self

Merge #2419

2419: Remove ns-polymorphic type_for_def r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Remove ns-polymorphic type_for_def

Hide MacroCallLoc

Merge #2415

2415: Add note r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Add note

Cleanup imports

Reduce visibility

Use TraitId in TraitRef

Merge #2413

2413: Remove another helper r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Remove another helper

Doc

Remove assoc_type_by_name helper

Store names in TraitData

Detangle ty from traits a bit

Merge #2412

2412: Fix stale crates that snuck in r=kjeremy a=kjeremy

Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>

Fix stale crates that snuck in

Merge #2406

2406: Add hygiene information to SourceAnalyzer r=matklad a=edwin0cheng

This should fix https://github.com/rust-analyzer/rust-analyzer/pull/2392#issuecomment-557964686

Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>

Remove dbg!

Merge #2410

2410: Introduce hir_ty r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Doc primitives

id-ify impls_in_crate_query

Merge #2411

2411: Update parking_lot and smallvec to drop some dependencies r=matklad a=kjeremy

Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>

Update parking_lot and smallvec to drop some dependencies

Introduce hir_ty

Merge #2409

2409: Id-ify Ty::Adt r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Id-ify Ty::Adt

Merge #2398

2398: WIP: introduce hir::Type r=matklad a=matklad

This introduces `hir::Type` wrapper over `hir::Ty`, with two purposes:

* bind `Ty` and it's corresponding environment
  * Am I correct that `Ty` without an env doesn't make much sense, because the meaning of type parameters is unclear
  * Am I correct that we can safely re-use the same environment for all types derived from the given type?
* hide representation defails of `Ty`. Specifically, I want to change `Ty::Adt` to use `hir_def::AdtId` instead of `hir::Adt`, but IDE doesn't know about underlying IDs. More generally, I feel like IDE shouldn't know that `Ty` is enum.

@flodiebold what do you think about this?

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Introduce hir::Type

It should provide a convenient API over more low-level Ty

Merge #2408

2408: Use chalk fork to paper over #2052 r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Use chalk fork to paper over #2052

Merge #2407

2407: :arrow_up: salsa r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

:arrow_up: salsa

Add hygiene information to SourceAnalyzer

Merge #2404

2404: Use TypeAliasId in Ty, pt 2 r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Use TypeAliasId in Ty, pt 2

Use TypeAliasId in Ty, pt 1

More ids in Ty

Merge #2403

2403: Fixme for union fields r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Fixme for union fields

Fix hir for ast::UnionDef

Introduce dedicated AST node for union

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.

Merge #2388

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>

Merge #2402

2402: Use ids for Callable r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Use ids for Callable

Merge #2401

2401: Update crates r=matklad a=kjeremy

Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>

Use more IDs

Update crates

Merge #2400

2400: Use GenericDefIdMore r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Use GenericDefIdMore

Merge #2399

2399: Use GenericDefId more r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Use GenericDefId more

Merge #2397

2397: Remove Resolver from autoderef r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Remove Resolver from autoderef

Resolver holds onto too much context, including local scopes. Let's
try to pass in only what is necessary -- the trait environment.

Push resolver up

Merge #2362

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>

Merge #2392

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>

Expand compile_error!

Fix panic during the expansion of `column!`

Merge #2396

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>

Switch to variant-granularity field type inference

Merge #2394

2394: Implement HasModule for AdtId r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Implement HasModule for AdtId

Merge #2393

2393: Simplify ADT fields r=matklad a=matklad

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

Simplify ADT fields