aboutsummaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
| * | Fix panic during the expansion of `column!`Marco Groppo2019-11-241-5/+16
| | |
* | | Merge #2396bors[bot]2019-11-2410-42/+68
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | Switch to variant-granularity field type inferenceAleksey Kladov2019-11-2410-42/+68
| | | |
* | | | Implement HasModule for AdtIdAleksey Kladov2019-11-242-9/+13
|/ / /
* | | Simplify ADT fieldsAleksey Kladov2019-11-245-26/+29
| | |
* | | Remove impl_block moduleAleksey Kladov2019-11-244-55/+43
| | |
* | | hir_def is fully doc'ed!Aleksey Kladov2019-11-243-5/+8
| | |
* | | SimplifyAleksey Kladov2019-11-248-104/+30
| | |
* | | DocsAleksey Kladov2019-11-242-2/+4
| | |
* | | Don't redo field resolution in the IDEAleksey Kladov2019-11-246-22/+30
| |/ |/|
* | Merge #2387bors[bot]2019-11-2415-96/+74
|\ \ | | | | | | | | | | | | | | | | | | | | | 2387: Simplify r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | SimplifyAleksey Kladov2019-11-248-33/+17
| | |
| * | Cleanup nameresAleksey Kladov2019-11-245-35/+19
| | |
| * | Use Trace in raw_itemsAleksey Kladov2019-11-243-29/+39
| |/
* | Merge #2381bors[bot]2019-11-243-1/+30
|\ \ | |/ |/| | | | | | | | | | | | | 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 <[email protected]>
| * add proc-macro crate type handlingJasperDeSutter2019-11-243-1/+30
| |
* | Some docsAleksey Kladov2019-11-244-11/+18
| |
* | CleanupAleksey Kladov2019-11-247-20/+15
| |
* | Reduce visibilityAleksey Kladov2019-11-242-8/+11
| |
* | Merge #2383bors[bot]2019-11-242-0/+10
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | Add alloc to the sysrootMarco Groppo2019-11-242-0/+10
| |/
* | Nicer API for attrsAleksey Kladov2019-11-244-32/+38
| |
* | Slightly reduce code duplicationAleksey Kladov2019-11-243-33/+30
| |
* | SimplifyAleksey Kladov2019-11-242-19/+5
| |
* | SimplifyAleksey Kladov2019-11-242-16/+3
| |
* | Switch to StaticLoc for staticsAleksey Kladov2019-11-2413-28/+65
| |
* | Remove ids moduleAleksey Kladov2019-11-246-41/+33
| |
* | Pull macro upAleksey Kladov2019-11-243-28/+16
| |
* | Cleanup importsAleksey Kladov2019-11-248-27/+20
| |
* | Push poison_macros downAleksey Kladov2019-11-242-25/+28
| |
* | Reduce visbilityAleksey Kladov2019-11-241-10/+10
|/
* Merge #2378bors[bot]2019-11-241-3/+6
|\ | | | | | | | | | | | | | | 2378: Fix panic in batch analysis r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * Fix panic in batch analysisAleksey Kladov2019-11-241-3/+6
| | | | | | | | Closes #2272
* | Merge #2365bors[bot]2019-11-241-9/+31
|\ \ | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | Improve fail case in expand_macroEdwin Cheng2019-11-231-9/+31
| | |
* | | Merge #2343bors[bot]2019-11-247-35/+155
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | do refact and fix some issuebravomikekilo2019-11-246-58/+70
| | | |
| * | | fix tidy testbravomikekilo2019-11-211-7/+11
| | | |
| * | | initial invert_ifbravomikekilo2019-11-214-1/+105
| | | |
* | | | Merge #2360bors[bot]2019-11-244-42/+184
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | 2360: Refactor builtin macro r=matklad a=edwin0cheng Refactor builtin macro and add some local tests. Co-authored-by: Edwin Cheng <[email protected]>
| * | | Use macro for all the thingsEdwin Cheng2019-11-231-48/+31
| | | |
| * | | Rename BuiltinExpander to BuiltinFnLikeExpanderEdwin Cheng2019-11-233-14/+14
| | | |
| * | | Refactor builtin macroEdwin Cheng2019-11-221-18/+124
| | | |
| * | | Add TestDBEdwin Cheng2019-11-222-0/+53
| | | |
* | | | Move ModuleSource back to hirAleksey Kladov2019-11-234-78/+71
| | | |
* | | | Privatise nameresAleksey Kladov2019-11-237-10/+12
| | | |
* | | | Rename CrateModuleIdAleksey Kladov2019-11-238-54/+54
| | | |
* | | | Move ImportIdAleksey Kladov2019-11-235-28/+26
| | | |
* | | | Simplify HasSourceAleksey Kladov2019-11-231-21/+18
| | | |
* | | | Hide ImportIdAleksey Kladov2019-11-234-21/+26
| | | |