aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * Drop some unused methodsAleksey Kladov2019-12-082-49/+5
| |
| * Cleanup Field tyAleksey Kladov2019-12-082-26/+47
| |
| * Cleanup Crate APIAleksey Kladov2019-12-085-32/+42
| |
* | Merge #2466bors[bot]2019-12-084-44/+194
|\ \ | |/ |/| | | | | | | | | | | | | | | | | 2466: Handle partial resolve cases r=matklad a=edwin0cheng Another try to fix #2443 : We resolve all imports every time in `DefCollector::collect` loop even it is resolved previously. This is because other unresolved imports and macros will bring in another `PerNs`, so we can only assume that it has been partially resolved. Co-authored-by: Edwin Cheng <[email protected]>
| * Refactor resolve_imports logicEdwin Cheng2019-12-072-40/+129
| |
| * Push glob_imports only if non-existsEdwin Cheng2019-12-071-4/+4
| |
| * Add testsEdwin Cheng2019-12-062-0/+61
| |
* | Merge #2497bors[bot]2019-12-087-70/+52
|\ \ | | | | | | | | | | | | | | | | | | | | | 2497: Remove MacroFileKind r=matklad a=edwin0cheng This PR move `to_macro_file_kind` to `hir_expand::db` and use it to get the `FragmentKind` directly, such that we can remove `MacroFileKind`. Co-authored-by: Edwin Cheng <[email protected]>
| * | Remove MacroFileKindEdwin Cheng2019-12-087-70/+52
|/ /
* | Merge #2495bors[bot]2019-12-071-0/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | 2495: Discover type parameters in more cases r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | Discover type parameters in more casesAleksey Kladov2019-12-071-0/+5
|/ /
* | Merge #2494bors[bot]2019-12-0719-92/+272
|\ \ | | | | | | | | | | | | | | | | | | | | | 2494: Get the right analyzer for impls r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | Rename GenericParam -> TypeParamAleksey Kladov2019-12-0718-79/+77
| | | | | | | | | | | | We don't have LifetimeParam yet, but they are planned!
| * | Get the right analyzer for implsAleksey Kladov2019-12-074-2/+23
| | |
| * | Classify name works for TypeParamsAleksey Kladov2019-12-076-5/+68
| | |
| * | Gotodef for TypeParametersAleksey Kladov2019-12-071-7/+18
| | |
| * | ToNav for GenericParamAleksey Kladov2019-12-072-1/+28
| | |
| * | Track source of type parametersAleksey Kladov2019-12-072-23/+82
| | |
| * | MinorAleksey Kladov2019-12-071-3/+4
|/ /
* | Merge #2493bors[bot]2019-12-071-16/+15
|\ \ | | | | | | | | | | | | | | | | | | | | | 2493: Show type hints for & patterns r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | Show type hints for & patternsAleksey Kladov2019-12-071-16/+15
|/ /
* | Merge pull request #2491 from matklad/skip-heavy-tests-by-defaultAleksey Kladov2019-12-073-3/+54
|\ \ | | | | | | Skip slow tests by default
| * | Skip slow tests by defaultAleksey Kladov2019-12-073-3/+54
| | |
* | | Merge #2492bors[bot]2019-12-0711-180/+213
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2492: Refactor generic parameteres lowering r=flodiebold a=matklad indices and parent params seem to be concerns, specific to `hir_ty`, so move them there. Co-authored-by: Aleksey Kladov <[email protected]>
| * | | ReformatAleksey Kladov2019-12-071-2/+2
| | | |
| * | | Refactor parameter count trackingAleksey Kladov2019-12-076-32/+30
| | | |
| * | | Remove idx and parent generics from genericsAleksey Kladov2019-12-0710-157/+181
| | | | | | | | | | | | | | | | | | | | This makes `hir_def::GenericParams` flatter. The logic for re-numbering the params is moved to hir instead.
| * | | Store GenericParams in arenaAleksey Kladov2019-12-074-14/+25
|/ / /
* | | Merge #2490bors[bot]2019-12-071-24/+21
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 2490: Get rid of unwraps in add_new r=matklad a=flodiebold Probably fixes #2464. Co-authored-by: Florian Diebold <[email protected]>
| * | Get rid of unwraps in add_newFlorian Diebold2019-12-071-24/+21
|/ / | | | | | | Probably fixes #2464.
* | Merge #2489bors[bot]2019-12-066-65/+194
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2489: Implement `format_args` r=flodiebold a=flodiebold This fixes a huge amount of type mismatches (because every format call was a type mismatch so far); I also hoped to get go to def working within `format!` etc., and the test says it should, but in practice it still doesn't seem to... Also remove the `len` parameter from `Name::new_inline_ascii`, which I'm assuming was only there because of `const fn` limitations? cc @edwin0cheng Co-authored-by: Florian Diebold <[email protected]>
| * | Implement ancestors_with_macros in a better wayFlorian Diebold2019-12-062-12/+22
| | |
| * | Make the goto_through_format test actually fail :(Florian Diebold2019-12-061-0/+3
| | |
| * | Builtin macros only use caller tokensFlorian Diebold2019-12-061-2/+2
| | |
| * | Try to make go to definition work in format!Florian Diebold2019-12-063-5/+63
| | | | | | | | | | | | | | | | | | | | | SourceAnalyzer didn't work properly within expression macro expansions because it didn't find the enclosing function. Fix this by going up the expansion chain to find ancestors. This makes the test work, but apparently in real usage it's still not working.
| * | Implement format_args more properlyFlorian Diebold2019-12-061-4/+43
| | |
| * | Remove unnecessary len parameter for Name::new_inline_asciiFlorian Diebold2019-12-061-59/+59
| | | | | | | | | | | | | | | I assume it was previously required because `len` was not const, but that doesn't seem to be a problem anymore.
| * | Add stub implementation of format_args{_nl} macrosFlorian Diebold2019-12-062-1/+20
| | | | | | | | | | | | Just enough to fix the huge amount of type mismatches they cause.
* | | Merge #2484bors[bot]2019-12-0610-318/+362
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | 2484: DynMap r=matklad a=matklad Implement a `DynMap` a semi-dynamic, semi-static map, which helps to thread heterogeneously typed info in a uniform way. Totally inspired by https://github.com/JetBrains/kotlin/blob/df3bee30384787d8951ea548a4257c2cb52a16a3/compiler/frontend/src/org/jetbrains/kotlin/resolve/BindingContext.java. @flodiebold wdyt? Seems like a potentially useful pattern for various source-map-like things. Co-authored-by: Aleksey Kladov <[email protected]>
| * | DynMapAleksey Kladov2019-12-0610-318/+362
| | | | | | | | | | | | | | | This might, or might not help us to reduce boilerplate associated with plumbing values from analysis to the IDE layer
* | | Merge #2481bors[bot]2019-12-061-2/+0
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | 2481: Remove obsolete comment r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | Remove obsolete commentAleksey Kladov2019-12-051-2/+0
| | |
* | | Merge #2487bors[bot]2019-12-063-11/+72
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | 2487: Don't unify within a reference r=matklad a=flodiebold 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. Co-authored-by: Florian Diebold <[email protected]>
| * | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-22 05:01:27 +0000