aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir/src
Commit message (Collapse)AuthorAgeFilesLines
* Complete union fields after dotJonas Schievink2020-04-281-12/+15
|
* Don't add call parens when an fn type is expectedJonas Schievink2020-04-251-0/+7
|
* Rename StructField -> FieldAleksey Kladov2020-04-257-66/+57
|
* Convert code to text-sizeAleksey Kladov2020-04-252-18/+18
|
* Do not add default and closure types in 'add explicit type' assistKirill Bulatov2020-04-211-0/+4
|
* Fix goto definition for record patternsAleksey Kladov2020-04-182-0/+15
|
* Merge #4029bors[bot]2020-04-181-0/+11
|\ | | | | | | | | | | | | | | | | | | | | | | | | 4029: Fix various proc-macro bugs r=matklad a=edwin0cheng This PRs does the following things: 1. Fixed #4001 by splitting `LIFETIME` lexer token to two mbe tokens. It is because rustc token stream expects `LIFETIME` as a combination of punct and ident, but RA `tt:TokenTree` treats it as a single `Ident` previously. 2. Fixed #4003, by skipping `proc-macro` for completion. It is because currently we don't have `AstNode` for `proc-macro`. We would need to redesign how to implement `HasSource` for `proc-macro`. 3. Fixed a bug how empty `TokenStream` merging in `proc-macro-srv` such that no L_DOLLAR and R_DOLLAR will be emitted accidentally. Co-authored-by: Edwin Cheng <[email protected]>
| * Ignore proc-macro in completionEdwin Cheng2020-04-181-0/+11
| |
* | Don't use SyntaxNodePtr::range when determining scope for offsetAleksey Kladov2020-04-171-47/+52
|/
* Correctly highlight ranges of diagnostics from macrosAleksey Kladov2020-04-171-0/+8
| | | | closes #2799
* diagnostics cli, iterate over membersJosh Mcguigan2020-04-151-1/+5
|
* Remove dead codeAleksey Kladov2020-04-111-4/+2
|
* Make records grammar more orthogonalAleksey Kladov2020-04-111-16/+14
| | | | | | | | | | | | We used name [: expr] grammar before, now it is [name :] expr which makes things simpler
* add record pat missing field diagnosticJosh Mcguigan2020-04-101-1/+1
|
* Move computation of missing fields into hirAleksey Kladov2020-04-073-51/+98
|
* missing match arms diagnosticJosh Mcguigan2020-04-071-1/+1
|
* Merge pull request #3866 from lnicola/fewer-bracesAleksey Kladov2020-04-071-9/+9
|\ | | | | Fix unnecessary braces warnings
| * Fix unnecessary braces warningsLaurențiu Nicola2020-04-061-9/+9
| |
* | Check for eprintln on CIAleksey Kladov2020-04-061-1/+1
|/
* Cleanup checking for existing impls in impl From assistMatthew Hall2020-04-021-33/+21
| | | | | Use the trait solver to check if there's an existing implementation of From<type_in_enum_variant> for the enum.
* Add impl From for enum variant assistMatthew Hall2020-04-011-1/+33
| | | | | | Basically adds a From impl for tuple enum variants with one field. Added to cover the fairly common case of implementing your own Error that can be created from another one, although other use cases exist.
* Cleanup memory usage statsAleksey Kladov2020-03-251-3/+4
|
* fix typo of visibility_ofEdwin Cheng2020-03-251-1/+1
|
* Always expand macros during analysisAleksey Kladov2020-03-252-21/+29
|
* Add ItemScope::visibility_ofEdwin Cheng2020-03-242-1/+5
|
* Use more generic public apiKirill Bulatov2020-03-242-21/+21
|
* Remove the upcastKirill Bulatov2020-03-241-3/+7
|
* Auto import macrosKirill Bulatov2020-03-241-12/+19
|
* Merge pull request #3686 from Veetaha/feature/hover-actual-type-paramsAleksey Kladov2020-03-232-15/+17
|\ | | | | ra_hir: add more privacy for Type
| * ra_hir: add more privacy for Typeveetaha2020-03-232-15/+17
| |
* | Merge pull request #3678 from edwin0cheng/refactor-renameAleksey Kladov2020-03-231-1/+28
|\ \ | | | | | | Fix rename argument in macro call
| * | Fix typoEdwin Cheng2020-03-221-1/+1
| | | | | | | | | Co-Authored-By: Veetaha <[email protected]>
| * | Add find_node_at_offset_with_descendEdwin Cheng2020-03-221-1/+28
| | |
* | | ra_hir: fix typoveetaha2020-03-231-1/+1
| | |
* | | ra_hir: add more docsveetaha2020-03-231-0/+12
| |/ |/|
* | ra_hir: migrate some stuff to matches!()veetaha2020-03-221-18/+6
|/
* Use `dyn Trait` for working with databseAleksey Kladov2020-03-165-262/+265
| | | | | | | It improves compile time in `--release` mode quite a bit, it doesn't really slow things down and, conceptually, it seems closer to what we want the physical architecture to look like (we don't want to monomorphise EVERYTHING in a single leaf crate).
* Fix completion of HashMap::newFlorian Diebold2020-03-131-2/+10
| | | | | | | | | | | | | | | The `ty` function in code_model returned the type with placeholders for type parameters. That's nice for printing, but not good for completion, because placeholders won't unify with anything else: So the type we got for `HashMap` was `HashMap<K, V, T>`, which doesn't unify with `HashMap<?, ?, RandomState>`, so the `new` method wasn't shown. Now we instead return `HashMap<{unknown}, {unknown}, {unknown}>`, which does unify with the impl type. Maybe we should just expose this properly as variables though, i.e. we'd return something like `exists<type, type, type> HashMap<?0, ?1, ?2>` (in Chalk notation). It'll make the API more complicated, but harder to misuse. (And it would handle cases like `type TypeAlias<T> = HashMap<T, T>` more correctly.)
* Restore cargo-fmt gatingAleksey Kladov2020-03-132-13/+9
|
* fix issue 3444Josh Mcguigan2020-03-132-11/+45
|
* SimplifyAleksey Kladov2020-03-091-1/+1
|
* Use `Index` for CrateGraphAleksey Kladov2020-03-091-5/+4
|
* Merge #3519bors[bot]2020-03-091-5/+32
|\ | | | | | | | | | | | | | | 3519: Show mod path on hover r=matklad a=SomeoneToIgnore Closes #1064 Co-authored-by: Kirill Bulatov <[email protected]>
| * Less abstract CrateData apiKirill Bulatov2020-03-091-5/+8
| |
| * Show mod path in hover tooltipKirill Bulatov2020-03-071-0/+24
| |
* | Merge #3513bors[bot]2020-03-091-1/+34
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3513: Completion in macros r=matklad a=flodiebold I experimented a bit with completion in macros. It's kind of working, but there are a lot of rough edges. - I'm trying to expand the macro call with the inserted fake token. This requires some hacky additions on the HIR level to be able to do "hypothetical" expansions. There should probably be a nicer API for this, if we want to do it this way. I'm not sure whether it's worth it, because we still can't do a lot if the original macro call didn't expand in nearly the same way. E.g. if we have something like `println!("", x<|>)` the expansions will look the same and everything is fine; but in that case we could maybe have achieved the same result in a simpler way. If we have something like `m!(<|>)` where `m!()` doesn't even expand or expands to something very different, we don't really know what to do anyway. - Relatedly, there are a lot of cases where this doesn't work because either the original call or the hypothetical call doesn't expand. E.g. if we have `m!(x.<|>)` the original token tree doesn't parse as an expression; if we have `m!(match x { <|> })` the hypothetical token tree doesn't parse. It would be nice if we could have better error recovery in these cases. Co-authored-by: Florian Diebold <[email protected]>
| * | Move hypothetical expansion to hir_expandFlorian Diebold2020-03-081-21/+3
| | |
| * | Try to complete within macrosFlorian Diebold2020-03-071-2/+53
| |/
* | Handle visibility for assoc item path completion as wellFlorian Diebold2020-03-081-8/+40
| |
* | Handle visibility for path completion (not in all cases yet)Florian Diebold2020-03-081-1/+11
| |