aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | Don't unify within a referenceFlorian Diebold2019-12-063-11/+72
|/ / | | | | | | | | | | | | If we are expecting a `&Foo` and get a `&something`, when checking the `something`, we are *expecting* a `Foo`, but we shouldn't try to unify whatever we get with that expectation, because it could actually be a `&Foo`, and `&&Foo` coerces to `&Foo`. So this fixes quite a few false type mismatches.
* | Merge #2486bors[bot]2019-12-061-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2486: Fix npm vulnerability warning r=matklad a=edwin0cheng I see a warning in `npm` when I try to install RA: ``` found 1 high severity vulnerability ``` This PR update package-lock.json by run `npm audit fix` Co-authored-by: Edwin Cheng <[email protected]>
| * | Fix npm vulnerability warningEdwin Cheng2019-12-061-3/+3
|/ /
* | Merge #2483bors[bot]2019-12-051-13/+10
|\ \ | | | | | | | | | | | | | | | | | | | | | 2483: Simplify test r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | Simplify testAleksey Kladov2019-12-051-13/+10
|/ /
* | Merge #2479bors[bot]2019-12-0520-81/+632
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | 2479: Add expansion infrastructure for derive macros r=matklad a=flodiebold I thought I'd experiment a bit with attribute macro/derive expansion, and here's what I've got so far. It has dummy implementations of the Copy / Clone derives, to show that the approach works; it doesn't add any attribute macro support, but I think that fits into the architecture. Basically, during raw item collection, we look at the attributes and generate macro calls for them if necessary. Currently I only do this for derives, and just add the derive macro calls as separate calls next to the item. I think for derives, it's important that they don't obscure the actual item, since they can't actually change it (e.g. sending the item token tree through macro expansion unnecessarily might make completion within it more complicated). Attribute macros would have to be recognized at that stage and replace the item (i.e., the raw item collector will just emit an attribute macro call, and not the item). I think when we implement this, we should try to recognize known inert attributes, so that we don't do macro expansion unnecessarily; anything that isn't known needs to be treated as a possible attribute macro call (since the raw item collector can't resolve the macro yet). There's basically no name resolution for attribute macros implemented, I just hardcoded the built-in derives. In the future, the built-ins should work within the normal name resolution infrastructure; the problem there is that the builtin stubs in `std` use macros 2.0, which we don't support yet (and adding support is outside the scope of this). One aspect that I don't really have a solution for, but I don't know how important it is, is removing the attribute itself from its input. I'm pretty sure rustc leaves out the attribute macro from the input, but to do that, we'd have to create a completely new syntax node. I guess we could do it when / after converting to a token tree. Co-authored-by: Florian Diebold <[email protected]>
| * Implement all the other built-in derivesFlorian Diebold2019-12-052-15/+86
| | | | | | | | Since as long as we're not implementing the bodies, they all work the same way.
| * Implement derive(Copy, Clone) properly (well, kind of)Florian Diebold2019-12-053-7/+241
| |
| * Don't wrap most syntax trees in invisible delimiters when converting to ↵Florian Diebold2019-12-051-2/+8
| | | | | | | | | | | | token tree Otherwise parsing them again doesn't work.
| * Add expansion infrastructure for derive macrosFlorian Diebold2019-12-0518-79/+319
| |
* | Merge #2480bors[bot]2019-12-053-99/+325
|\ \ | |/ |/| | | | | | | | | | | 2480: New from sorce infra r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * Reduce copy-pasteAleksey Kladov2019-12-051-20/+30
| |
| * Introduce ChildFromSourceAleksey Kladov2019-12-053-101/+317
|/
* Merge #2474bors[bot]2019-12-0510-136/+149
|\ | | | | | | | | | | | | | | 2474: Move `ModuleSource`, create `ModuleOrigin` r=matklad a=ice1000 As title. This comes right after #2473 Co-authored-by: ice1000 <[email protected]>
| * Publicize `file_id` to make `test_db` compileice10002019-12-051-1/+1
| |
| * Use placeholder instead of `Option`ice10002019-12-052-14/+10
| |
| * One pub function less is good!ice10002019-12-053-12/+7
| |
| * Reduce visibility, use struct instead of tuplesice10002019-12-051-20/+23
| |
| * No block at the momentice10002019-12-045-14/+3
| |
| * Remove almost unused `ModuleSource::new`ice10002019-12-042-20/+2
| |
| * Confluent `ModuleSource` usageice10002019-12-042-18/+6
| |
| * Add `ModuleSource::Block`ice10002019-12-049-100/+102
| |
| * Fix test compilationice10002019-12-042-2/+2
| |
| * Three-state enum for module originice10002019-12-042-20/+78
|/
* Merge #2478bors[bot]2019-12-041-3/+3
|\ | | | | | | | | | | | | | | 2478: :arrow_up: rowan r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * :arrow_up: rowanAleksey Kladov2019-12-041-3/+3
| |
* | Merge #2477bors[bot]2019-12-044-0/+78
|\ \ | |/ |/| | | | | | | | | | | | | 2477: Run rustfmt with respect to Cargo.toml edition r=matklad a=Speedy37 Fixes #2146 Fixes #1959 Co-authored-by: Vincent Rouillé <[email protected]>
| * Run rustfmt with respect to Cargo.toml editionVincent Rouillé2019-12-044-0/+78
|/
* Merge #2476bors[bot]2019-12-045-11/+12
|\ | | | | | | | | | | | | | | 2476: :arrow_up: rowan r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * :arrow_up: rowanAleksey Kladov2019-12-045-11/+12
| |
* | Merge #2475bors[bot]2019-12-041-1/+1
|\ \ | |/ |/| | | | | | | | | | | 2475: fix outdated link to ra-emacs-lsp.el r=matklad a=andrewbanchich Co-authored-by: Andrew Banchich <[email protected]>
| * fix file nameAndrew Banchich2019-12-041-1/+1
| |
| * fix linkAndrew Banchich2019-12-041-1/+1
| |
| * use relative linkAndrew Banchich2019-12-041-1/+1
| |
| * fix outdated link to ra-emacs-lsp.elAndrew Banchich2019-12-041-1/+1
|/
* Merge #2471bors[bot]2019-12-032-2/+4
|\ | | | | | | | | | | | | | | 2471: Add `ModuleItemsOwner` to `Block` r=matklad a=ice1000 As title Co-authored-by: ice1000 <[email protected]>
| * Add `ModuleItemsOwner` to `Block`ice10002019-12-032-2/+4
| |
* | Merge #2472bors[bot]2019-12-037-4902/+4882
|\ \ | |/ |/| | | | | | | | | | | 2472: Split up ty tests a bit r=matklad a=flodiebold `simple` is a bit of a kitchen sink (and not all of them are really about 'simple' features), suggestions for further divisions there are welcome :smile: Co-authored-by: Florian Diebold <[email protected]>
| * Split up ty tests a bitFlorian Diebold2019-12-037-4902/+4882
|/
* Merge #2469bors[bot]2019-12-0323-112/+69
|\ | | | | | | | | | | | | | | 2469: Replace `ra_hir_expand::either` with crate r=matklad a=ice1000 As title. Co-authored-by: ice1000 <[email protected]>
| * Replace `ra_hir_expand::either` with crateice10002019-12-0323-112/+69
|/
* Merge #2468bors[bot]2019-12-034-7/+65
|\ | | | | | | | | | | | | | | | | 2468: Fix #2467 r=flodiebold a=flodiebold The stand-alone `unify` requires that the type doesn't contain any type variables. So we can't share the code here for now (without more refactoring)... Co-authored-by: Florian Diebold <[email protected]>
| * Fix #2467Florian Diebold2019-12-034-7/+65
|/ | | | | The stand-alone `unify` requires that the type doesn't contain any type variables. So we can't share the code here for now (without more refactoring)...
* Merge #2465bors[bot]2019-12-033-127/+219
|\ | | | | | | | | | | | | | | 2465: Extract built-in trait implementations to separate module r=matklad a=flodiebold This untangles the builtin logic from the Chalk translation. Co-authored-by: Florian Diebold <[email protected]>
| * Extract built-in trait implementations to separate moduleFlorian Diebold2019-12-033-127/+219
| | | | | | | | This untangles the builtin logic from the Chalk translation.
* | Merge #2463bors[bot]2019-12-039-340/+570
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | 2463: More correct method resolution r=flodiebold a=flodiebold This should fix the order in which candidates for method resolution are considered, i.e. `(&Foo).clone()` should now be of type `Foo` instead of `&Foo`. It also checks for inherent candidates that the self type unifies properly with the self type in the impl (i.e. `impl Foo<u32>` methods will only be considered for `Foo<u32>`). To be able to get the correct receiver type to check in the method resolution, I needed the unification logic, so I extracted it to the `unify.rs` module. Should fix #2435. Co-authored-by: Florian Diebold <[email protected]>
| * Make unify pub(crate)Florian Diebold2019-12-031-1/+1
| |
| * Add tests for checking the impl self typeFlorian Diebold2019-12-022-0/+47
| |
| * Refactor a bitFlorian Diebold2019-12-023-77/+74
| |
| * Check receiver type properlyFlorian Diebold2019-12-024-19/+80
| |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 04:37:10 +0000