aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge #1877bors[bot]2019-09-1914-87/+87
|\ | | | | | | | | | | | | | | 1877: Replace usages of bump_any with bump r=matklad a=kjeremy Fixes #1854 Co-authored-by: kjeremy <[email protected]>
| * Replace usages of bump_any with bumpkjeremy2019-09-1914-87/+87
|/
* Merge #1853bors[bot]2019-09-1913-138/+294
|\ | | | | | | | | | | | | | | | | 1853: Introduce FromSource trait r=matklad a=viorina The idea is to provide an ability to get HIR from AST in a more general way than it's possible using `source_binder`. It also could help with #1622 fixing. Co-authored-by: Ekaterina Babshukova <[email protected]>
| * introduce FromSource traitEkaterina Babshukova2019-09-1913-138/+294
| |
* | Merge #1873bors[bot]2019-09-191-0/+15
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 1873: `fold_kind`: `MATCH_ARM_LIST => FoldKind::Block` r=matklad a=Centril As suggested by @matklad in https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/folding.20of.20.60match.60.20and.20.60if.60/near/176109093. This should let folks fold all the arms in a `match` expression rather than just each arm individually. Co-authored-by: Mazdak Farrokhzad <[email protected]>
| * | Pacify rustfmt.Mazdak Farrokhzad2019-09-191-4/+1
| | |
| * | `fold_kind`: `MATCH_ARM_LIST => FoldKind::Block`Mazdak Farrokhzad2019-09-191-0/+18
| | |
* | | Merge #1874bors[bot]2019-09-192-34/+28
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 1874: move fold conversino to conv.rs r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | move fold conversino to conv.rsAleksey Kladov2019-09-192-34/+28
| | |
| * | fix typoAleksey Kladov2019-09-191-1/+1
| |/
* | Merge #1872bors[bot]2019-09-191-185/+159
|\ \ | |/ |/| | | | | | | | | | | 1872: slightly cleanup macro tests r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * slightly cleanup macro testsAleksey Kladov2019-09-191-185/+159
|/
* Merge #1868bors[bot]2019-09-181-1/+1
|\ | | | | | | | | | | | | | | 1868: Fixed markdown in user README r=kjeremy a=zoewithabang Link pointing to the GitHub issue regarding why a full restart of VS Code is needed was broken. Co-authored-by: zoewithabang <[email protected]>
| * Fixed markdown in user READMEzoewithabang2019-09-181-1/+1
|/
* Merge #1867bors[bot]2019-09-183-21/+32
|\ | | | | | | | | | | | | | | 1867: tweak installation process r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * tweak installation processAleksey Kladov2019-09-183-21/+32
|/
* Merge #1861bors[bot]2019-09-183-28/+74
|\ | | | | | | | | | | | | | | 1861: account for impls generated by macros r=matklad a=matklad The code is pretty horrible and is copy-pased from expressions. We really need to find a better way to lower stuff generated by macros. But it gets the job done! I've actually though that we did this ages ago, but obviously we didn't Co-authored-by: Aleksey Kladov <[email protected]>
| * account for impls generated by macrosAleksey Kladov2019-09-183-28/+74
|/
* Merge #1862bors[bot]2019-09-1719-261/+358
|\ | | | | | | | | | | | | | | 1862: Assoc item resolution refactoring (again) r=flodiebold a=flodiebold This is #1849, with the associated type selection code removed for now. Handling cycles there will need some more thought. Co-authored-by: Florian Diebold <[email protected]>
| * Remove assoc type selection code for now to fix crashesFlorian Diebold2019-09-172-25/+10
| |
| * Add test for `T::Item` cyclesFlorian Diebold2019-09-171-0/+42
| |
| * Remove TraitItem and ImplItem in favor of AssocItemFlorian Diebold2019-09-179-93/+46
| |
| * Small review improvementsFlorian Diebold2019-09-171-5/+3
| |
| * Add test for `<T>::Item`Florian Diebold2019-09-171-10/+22
| |
| * Refactor some moreFlorian Diebold2019-09-174-57/+100
| | | | | | | | | | | | Type-relative paths (`<T>::foo`) also need to work in type context, for example `<T>::Item` is legal. So rather than returning the type ref from the resolver function, just check it before.
| * Refactor associated item resolution moreFlorian Diebold2019-09-172-124/+120
| | | | | | | | | | When resolving an associated item in value namespace, use the `Ty` lowering code for the segments before the last instead of replicating it.
| * Refactor a bit to prepare for resolving trait assoc itemsFlorian Diebold2019-09-1710-52/+83
| |
| * Resolve assoc types on type parametersFlorian Diebold2019-09-172-24/+61
| | | | | | | | | | | | E.g. `fn foo<T: Iterator>() -> T::Item`. It seems that rustc does this only for type parameters and only based on their bounds, so we also only consider traits from bounds.
| * Adapt some testsFlorian Diebold2019-09-171-12/+12
| |
* | Merge #1860bors[bot]2019-09-171-31/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | 1860: remove confusing code r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | remove confusing codeAleksey Kladov2019-09-171-31/+1
| | | | | | | | | | | | | | | | | | I must confess I don't really understand what this code is trying to do, but it definitely misreports changes during fixedpoint iteration, and no tests fail if I remove it, so...
* | | Merge #1859bors[bot]2019-09-171-1/+1
|\| | | |/ |/| | | | | | | | | | | 1859: show error log by default r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * show error log by defaultAleksey Kladov2019-09-171-1/+1
|/
* Merge #1858bors[bot]2019-09-1710-933/+753
|\ | | | | | | | | | | | | | | 1858: use usual token tree for macro expansions r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * use usual token tree for macro expansionAleksey Kladov2019-09-1710-933/+753
| |
* | Merge #1855bors[bot]2019-09-173-418/+448
|\| | | | | | | | | | | | | | | 1855: split mbe expander code into two modules r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * split mbe expander code into two modulesAleksey Kladov2019-09-173-418/+448
|/
* Merge #1817bors[bot]2019-09-1612-148/+235
|\ | | | | | | | | | | | | | | 1817: Support path starting with a type r=matklad a=uHOOCCOOHu The path syntax `<Ty>::foo` Co-authored-by: uHOOCCOOHu <[email protected]>
| * Define known paths and group namesuHOOCCOOHu2019-09-156-49/+63
| |
| * Move store TypeRef of type based path in PathKinduHOOCCOOHu2019-09-154-21/+11
| |
| * Support path starting with a typeuHOOCCOOHu2019-09-1510-128/+211
| |
* | Merge #1852bors[bot]2019-09-162-5/+5
|\ \ | |/ |/| | | | | | | | | | | | | | | 1852: Gracefully handle `const _` items in `ConstData` r=ecstatic-morse a=ecstatic-morse A follow-up to #1847. This makes the `name` field of `ConstData` optional. Co-authored-by: Dylan MacKenzie <[email protected]>
| * Remove `is_unnamed`Dylan MacKenzie2019-09-161-4/+0
| |
| * Gracefully handle `const _` items in `ConstData`Dylan MacKenzie2019-09-162-5/+9
|/
* Merge #1848bors[bot]2019-09-1512-17/+573
|\ | | | | | | | | | | | | | | | | | | | | | | 1848: Parse `..` as a full pattern r=matklad a=ecstatic-morse Resolves #1479. This PR implements [RFC 2707](https://github.com/rust-lang/rfcs/pull/2707) in the parser. It introduces a new `DotDotPat` AST node modeled on `PlaceholderPat` and changes the parsing of tuple and slice patterns to conform to the RFC. Notably, this PR does *not* change the resulting AST when `..` appears in a struct pattern (e.g. `Struct { a, b: c, .. }`). I *think* this is the behavior mandated by RFC 2707, but someone should confirm this. Co-authored-by: Dylan MacKenzie <[email protected]>
| * Generate `dot_dot_test`Dylan MacKenzie2019-09-152-0/+481
| |
| * Bless old tests containing a `..` patternDylan MacKenzie2019-09-155-5/+10
| |
| * Parse `..` as a proper patternDylan MacKenzie2019-09-151-10/+42
| |
| * Add `DotDotPat` to ASTDylan MacKenzie2019-09-154-2/+40
| | | | | | | | This is modeled on `PlaceholderPat`.
* | Merge #1847bors[bot]2019-09-156-40/+90
|\ \ | |/ |/| | | | | | | | | | | 1847: Allow an underscore as the identifier in `const` items r=matklad a=ecstatic-morse [RFC 2526](https://github.com/rust-lang/rust/issues/54912) was recently stabilized, meaning `const _: i32 = 5;` is now a valid item. Co-authored-by: Dylan MacKenzie <[email protected]>