aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* | Merge #725bors[bot]2019-02-026-17/+83
|\ \ | | | | | | | | | | | | | | | | | | | | | 725: Implement `use as` r=matklad a=flodiebold Co-authored-by: Florian Diebold <[email protected]>
| * | Use aliases in import resolutionFlorian Diebold2019-02-011-9/+12
| | |
| * | Pass aliases to ImportDataFlorian Diebold2019-02-014-8/+47
| | |
| * | Add test for `use as`Florian Diebold2019-02-011-0/+24
|/ /
* | Merge #693bors[bot]2019-02-0126-421/+906
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 693: Name resolution refactoring r=matklad a=flodiebold This is still very WIP, but it's becoming quite big and I want to make sure this isn't going in a completely bad direction :sweat_smile:. I'm not really happy with how the path resolution looks, and I'm not sure `PerNs<Resolution>` is the best return type -- there are 'this cannot happen in the (types/values) namespace' cases everywhere. I also want to unify the `resolver` and `nameres` namespaces once I'm done switching everything to `Resolver`. Also, `Resolver` only has a lifetime because it needs to have a reference to the `ItemMap` during import resolution :confused: The differences in the completion snapshots are almost completely just ordering (except it completes `Self` as well now), so I changed it to sort the completions before snapshotting. Co-authored-by: Florian Diebold <[email protected]>
| * | Some cleanup and additional testsFlorian Diebold2019-02-017-31/+138
| | |
| * | Make the Resolution variants tuple variantsFlorian Diebold2019-02-017-53/+41
| | |
| * | CleanupFlorian Diebold2019-02-017-27/+17
| | |
| * | Use the new Resolver API for goto defFlorian Diebold2019-02-016-35/+89
| | |
| * | Use the new Resolver API in completionFlorian Diebold2019-02-0111-106/+190
| | |
| * | Use new Resolver API in type inferenceFlorian Diebold2019-02-0113-250/+296
| | |
| * | Implement methods to build a resolverFlorian Diebold2019-02-015-73/+166
| | |
| * | Sketching the resolver APIFlorian Diebold2019-02-018-11/+134
|/ /
* | Merge #718bors[bot]2019-02-0121-115/+162
|\ \ | | | | | | | | | | | | | | | | | | | | | 718: split HirDatabase r=matklad a=csmoe Closes #706 Co-authored-by: csmoe <[email protected]>
| * | split HirDatabase apicsmoe2019-02-0121-106/+147
| | |
| * | split hirdatabasecsmoe2019-02-011-20/+26
|/ /
* | Merge #722bors[bot]2019-02-015-73/+16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | 722: remove hard-coded support for ctry macro r=matklad a=matklad It was used mainly to prevent HirFileId infra from bitroting, but the `vec![]` macro can serve that just as well! Co-authored-by: Aleksey Kladov <[email protected]>
| * | remove hard-coded support for ctry macroAleksey Kladov2019-02-015-73/+16
|/ / | | | | | | | | It was used mainly to prevent HirFileId infra from bitroting, but the `vec![]` macro can serve that just as well!
* | Merge #721bors[bot]2019-02-013-26/+140
|\ \ | |/ |/| | | | | | | | | | | | | | | 721: Go To Implementation for Trait r=matklad a=kjeremy If on a trait def you can now go to all the impls of that trait in the crate. This is more of #620. Co-authored-by: kjeremy <[email protected]>
| * Go To Implementation for Traitkjeremy2019-01-313-26/+140
|/
* explain the magicAleksey Kladov2019-01-312-19/+56
|
* cleanup the apiAleksey Kladov2019-01-313-56/+70
|
* cleanupAleksey Kladov2019-01-313-40/+42
|
* move testAleksey Kladov2019-01-318-120/+129
|
* split macros across cratesAleksey Kladov2019-01-3111-29/+57
|
* preserve token spacingAleksey Kladov2019-01-317-30/+59
|
* first test sort-of passesAleksey Kladov2019-01-318-40/+215
|
* extract tt cursorAleksey Kladov2019-01-314-96/+101
|
* binders boilerplateAleksey Kladov2019-01-311-2/+42
|
* more expand boilerplateAleksey Kladov2019-01-313-4/+5
|
* more expand boilerplateAleksey Kladov2019-01-312-2/+24
|
* expand boilerplateAleksey Kladov2019-01-313-1/+10
|
* reshuffleAleksey Kladov2019-01-313-200/+210
|
* move macros to a separate crateAleksey Kladov2019-01-317-23/+50
|
* parses simple macroAleksey Kladov2019-01-313-23/+131
|
* handle multibyte tokensAleksey Kladov2019-01-312-23/+31
|
* add eat methodsAleksey Kladov2019-01-311-6/+23
|
* parsing scaffoldAleksey Kladov2019-01-311-4/+45
|
* debug implsAleksey Kladov2019-01-313-2/+47
|
* add repeats to astAleksey Kladov2019-01-311-0/+12
|
* convert punts and literalsAleksey Kladov2019-01-314-20/+127
|
* start tt convertions boilerplateAleksey Kladov2019-01-312-7/+43
|
* add conversion boilerplateAleksey Kladov2019-01-313-7/+17
|
* add macro by example ideAleksey Kladov2019-01-312-0/+52
|
* shorten name :-)Aleksey Kladov2019-01-312-1/+1
|
* start token tree moduleAleksey Kladov2019-01-312-0/+39
|
* Merge #715bors[bot]2019-01-311-1/+3
|\ | | | | | | | | | | | | | | 715: Use "▶" for test code lens r=matklad a=kjeremy I find that this makes code lenses stand out more otherwise they can be easy to miss. Co-authored-by: Jeremy Kolb <[email protected]>
| * formatJeremy Kolb2019-01-311-1/+3
| |
| * Use "▶" for test code lensJeremy Kolb2019-01-311-1/+1
| | | | | | | | I find that this makes code lenses stand out more.
* | Merge #692bors[bot]2019-01-3115-0/+432
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 692: [WIP] Correctly parse attributes r=matklad a=DJMcNab Reference - https://doc.rust-lang.org/reference/attributes.html This fixes/investigates inner attributes for: - [x] `impl` blocks - [x] `extern` blocks - [x] `fn`s (fixes #689) - [x] `mod`s (already supported) - [x] 'block expressions' (the long text just describes all 'blocks' used as statements) This also investigates/fixes outer attributes for: - [ ] 'most statements' (see also: #685, https://doc.rust-lang.org/reference/expressions.html#expression-attributes) - [x] Enum variants, Struct and Union fields (Fixed in #507) - [ ] 'Match expression arms' (@matklad can you provide a test case which explains what this means?) - [ ] 'Generic lifetime or type parameters' - [ ] 'Elements of array expressions, tuple expressions, call expressions, tuple-style struct and enum variant expressions' - [ ] 'The tail expression of block expressions' Co-authored-by: DJMcNab <[email protected]>