aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir
Commit message (Collapse)AuthorAgeFilesLines
* 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-133-11/+46
|
* 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-092-1/+36
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-072-2/+55
| |/
* | 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
| |
* | Handle visibility in method call completionFlorian Diebold2020-03-071-0/+8
|/
* Normalize waiting queries namesAleksey Kladov2020-03-061-5/+5
|
* Don't reuse the Chalk solverFlorian Diebold2020-03-061-2/+1
| | | | | This slows down analysis-stats a bit (~5% in my measurement), but improves incremental checking a lot because we can reuse trait solve results.
* Source map returns a resultAleksey Kladov2020-03-061-2/+2
| | | | cc #2236
* Move PathResolutionAleksey Kladov2020-03-053-19/+18
|
* Remove dead codeAleksey Kladov2020-03-051-7/+1
|
* Minor cleanupAleksey Kladov2020-03-041-16/+14
|
* Remove old find refs infraAleksey Kladov2020-03-042-41/+2
|
* Refactor reference search a bitAleksey Kladov2020-03-031-1/+11
|
* More principled approach for gotodef for field shorhandAleksey Kladov2020-03-022-10/+24
| | | | | Callers can now decide for themselves if they should prefer field or local definition. By default, it's the local.
* Rename ast::ImplBlock -> ast::ImplDefAleksey Kladov2020-02-297-30/+30
|
* Handle tuple fields as wellAleksey Kladov2020-02-292-1/+7
|
* MinorAleksey Kladov2020-02-292-5/+4
|
* Simplify SourceBinderAleksey Kladov2020-02-296-349/+321
|
* Small cleanupAleksey Kladov2020-02-291-9/+15
|
* Reduce visibilityAleksey Kladov2020-02-282-3/+3
|
* Merge #3367bors[bot]2020-02-282-7/+32
|\ | | | | | | | | | | | | | | | | | | | | 3367: Fix highlighting of const patterns r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * Fix highlighting of const patternsAleksey Kladov2020-02-282-7/+32
| |
* | Simpilfy origin_range logicEdwin Cheng2020-02-281-38/+27
|/
* Use text_range::extend_toEdwin Cheng2020-02-271-10/+3
|
* Skip trival token in original_rangeEdwin Cheng2020-02-261-5/+7
|
* Remove duplicate commentEdwin Cheng2020-02-261-1/+0
|
* Add recursive support in original_rangeEdwin Cheng2020-02-261-14/+37
|
* Remove dead codeAleksey Kladov2020-02-262-25/+9
|
* Reduce visibilityAleksey Kladov2020-02-263-76/+81
|
* Refactor primary IDE APIAleksey Kladov2020-02-264-215/+480
| | | | | | | | | | This introduces the new type -- Semantics. Semantics maps SyntaxNodes to various semantic info, such as type, name resolution or macro expansions. To do so, Semantics maintains a HashMap which maps every node it saw to the file from which the node originated. This is enough to get all the necessary hir bits just from syntax.
* Don't store deriveable Module info in NameDefinitionAleksey Kladov2020-02-191-1/+28
|
* Update versionsKirill Bulatov2020-02-181-3/+3
|
* More manual clippy fixesKirill Bulatov2020-02-181-21/+15
|
* Run cargo +nightly fix --clippy -Z unstable-optionsKirill Bulatov2020-02-182-8/+7
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-17 03:10:43 +0000