aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * Use TypeAliasId in Ty, pt 2Aleksey Kladov2019-11-255-46/+40
| |
| * Use TypeAliasId in Ty, pt 1Aleksey Kladov2019-11-252-11/+29
| |
| * More ids in TyAleksey Kladov2019-11-254-17/+13
|/
* Merge #2403bors[bot]2019-11-2527-98/+190
|\ | | | | | | | | | | | | | | 2403: Fixme for union fields r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * Fixme for union fieldsAleksey Kladov2019-11-254-0/+9
| |
| * Fix hir for ast::UnionDefAleksey Kladov2019-11-2522-86/+121
| |
| * Introduce dedicated AST node for unionAleksey Kladov2019-11-257-15/+63
|/ | | | | | | | | | 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 #2388bors[bot]2019-11-252-2/+8
|\ | | | | | | | | | | | | | | 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 <[email protected]>
| * Show missing struct fields in the error messageFrizi2019-11-242-2/+8
| |
* | Merge #2402bors[bot]2019-11-254-47/+64
|\ \ | | | | | | | | | | | | | | | | | | | | | 2402: Use ids for Callable r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | Use ids for CallableAleksey Kladov2019-11-254-34/+50
| | |
| * | Use more IDsAleksey Kladov2019-11-251-17/+18
| | |
* | | Merge #2401bors[bot]2019-11-251-56/+62
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 2401: Update crates r=matklad a=kjeremy Co-authored-by: Jeremy Kolb <[email protected]>
| * | Update cratesJeremy Kolb2019-11-251-56/+62
| | |
* | | Merge #2400bors[bot]2019-11-2510-56/+44
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2400: Use GenericDefIdMore r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Use GenericDefIdMoreAleksey Kladov2019-11-2510-56/+44
| | | |
* | | | Merge #2399bors[bot]2019-11-255-33/+20
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2399: Use GenericDefId more r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Use GenericDefId moreAleksey Kladov2019-11-255-33/+20
|/ / /
* | | Merge #2397bors[bot]2019-11-257-58/+85
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2397: Remove Resolver from autoderef r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Remove Resolver from autoderefAleksey Kladov2019-11-257-49/+73
| | | | | | | | | | | | | | | | | | | | Resolver holds onto too much context, including local scopes. Let's try to pass in only what is necessary -- the trait environment.
| * | | Push resolver upAleksey Kladov2019-11-251-12/+15
|/ / /
* | | Merge #2362bors[bot]2019-11-252-0/+39
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | Expand compile_error!Jeremy Kolb2019-11-252-0/+39
| | | |
* | | | Merge #2392bors[bot]2019-11-251-5/+16
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | 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
| | | | |
* | | | | Merge #2394bors[bot]2019-11-242-9/+13
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2394: Implement HasModule for AdtId r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Implement HasModule for AdtIdAleksey Kladov2019-11-242-9/+13
| | | | |
* | | | | Merge #2393bors[bot]2019-11-245-26/+29
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2393: Simplify ADT fields r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Simplify ADT fieldsAleksey Kladov2019-11-245-26/+29
|/ / / /
* | | | Merge #2391bors[bot]2019-11-248-61/+51
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2391: Simplify r=matklad a=matklad bors r+ Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Remove impl_block moduleAleksey Kladov2019-11-244-55/+43
| | | | |
| * | | | hir_def is fully doc'ed!Aleksey Kladov2019-11-244-6/+8
| | | | |
* | | | | Merge #2390bors[bot]2019-11-2410-106/+34
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2390: Simplify r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | SimplifyAleksey Kladov2019-11-248-104/+30
| | | | |
| * | | | DocsAleksey Kladov2019-11-242-2/+4
|/ / / /
* | | | Merge #2389bors[bot]2019-11-246-22/+30
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | 2389: Don't redo field resolution in the IDE r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | 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
| | | |
* | | | Merge #2385bors[bot]2019-11-2412-39/+44
|\ \ \ \ | | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | 2385: Some docs r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | | 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]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 21:38:14 +0000