aboutsummaryrefslogtreecommitdiff
path: root/crates/hir
Commit message (Collapse)AuthorAgeFilesLines
* Merge #5846bors[bot]2020-09-241-5/+31
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5846: Add references to fn args during completion r=matklad a=adamrk When completing a function call, if there is an argument taken as a ref or mut ref which matches the name and type of a variable in scope, we will insert a `&` or `&mut` when filling in the function arguments. This addresses https://github.com/rust-analyzer/rust-analyzer/issues/5449. E.g. ```rust fn foo(x: &i32) {} fn main() { let x = 5; foo # completing foo here generates `foo(&x)` now instead of `foo(x)` } ``` Co-authored-by: adamrk <[email protected]>
| * Remove exposing unificationadamrk2020-09-021-6/+0
| |
| * Add back Param structadamrk2020-09-011-2/+12
| |
| * Add references to fn args during completionadamrk2020-08-301-6/+28
| |
* | Apply suggestions from code reviewAleksey Kladov2020-09-211-5/+5
| | | | | | Co-authored-by: Laurențiu Nicola <[email protected]>
* | Document SemanticScopeAleksey Kladov2020-09-211-0/+19
| |
* | Rename `CustomDerive` to `ProcMacro`Jonas Schievink2020-09-181-2/+2
| | | | | | | | | | It handles fn-like macros too, and will handle attribute macros in the future
* | Merge #5971bors[bot]2020-09-131-0/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5971: Implement async blocks r=flodiebold a=oxalica Fix #4018 @flodiebold already gave a generic guide in the issue. Here's some concern about implementation detail: - Chalk doesn't support generator type yet. - Adding generator type as a brand new type (ctor) can be complex and need to *re-introduced* builtin impls. (Like how we implement closures before native closure support of chalk, which is already removed in #5401 ) - The output type of async block should be known after type inference of the whole body. - We cannot directly get the type from source like return-positon-impl-trait. But we still need to provide trait bounds when chalk asking for `opaque_ty_data`. - During the inference, the output type of async block can be temporary unknown and participate the later inference. `let a = async { None }; let _: i32 = a.await.unwrap();` So in this PR, the type of async blocks is inferred as an opaque type parameterized by the `Future::Output` type it should be, like what we do with closure type. And it really works now. Well, I still have some questions: - The bounds `AsyncBlockImplType<T>: Future<Output = T>` is currently generated in `opaque_ty_data`. I'm not sure if we should put this code here. - Type of async block is now rendered as `impl Future<Output = OutputType>`. Do we need to special display to hint that it's a async block? Note that closure type has its special format, instead of `impl Fn(..) -> ..` or function type. Co-authored-by: oxalica <[email protected]>
| * | Fix type walking about type of async blockoxalica2020-09-111-0/+5
| | |
| * | Implement async blocksoxalica2020-09-101-0/+2
| |/
* / Rename record_field_pat to record_pat_fieldPavan Kumar Sunkara2020-09-102-6/+6
|/
* Tease apart orthogonal concerns in markdown link rewritingAleksey Kladov2020-08-265-321/+65
| | | | | | | | | | | | `hir` should know nothing about URLs, markdown and html. It should only be able to: * resolve stringy path from documentation * generate canonical stringy path for a def In contrast, link rewriting should not care about semantics of paths and names resolution, and should be concern only with text mangling bits.
* Remove monomorphisation from doclinks resolving codeAleksey Kladov2020-08-252-34/+43
|
* Remove AttrDefAleksey Kladov2020-08-254-66/+52
|
* SimplifyAleksey Kladov2020-08-251-6/+6
|
* Move attrs from code_module to a separate moduleAleksey Kladov2020-08-253-126/+140
|
* MinorAleksey Kladov2020-08-251-9/+6
|
* Use the same abstraction for attrs and docsAleksey Kladov2020-08-252-9/+4
| | | | | Doc comments *are* attributes, so there's no reason to have two crates here.
* Merge remote-tracking branch 'upstream/master' into 503-hover-doc-linksZac Pullar-Strecker2020-08-251-8/+9
|\
| * Add description for crates that will be publishedPavan Kumar Sunkara2020-08-241-0/+1
| |
| * Add version to deps in cargo.tomlPavan Kumar Sunkara2020-08-241-7/+7
| |
* | Changes from reviewZac Pullar-Strecker2020-08-252-18/+23
| |
* | Renames, comments, and dead code removalZac Pullar-Strecker2020-08-243-22/+5
| |
* | Merge remote-tracking branch 'upstream/master' into 503-hover-doc-linksZac Pullar-Strecker2020-08-244-4/+353
|/
* :arrow_up: ungrammarAleksey Kladov2020-08-211-1/+1
|
* Better API factoring around self access modesAleksey Kladov2020-08-193-46/+14
|
* Introduce hir::ParamAleksey Kladov2020-08-191-2/+11
| | | | | We generally shouldn't expose TypeRef out of hir. So, let's just use a placehoder here.
* Add SelfParam to code_modelAleksey Kladov2020-08-193-24/+49
|
* Minor cleanupsAleksey Kladov2020-08-191-7/+6
|
* Merge #5643bors[bot]2020-08-193-5/+62
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5643: Add new consuming modifier, apply consuming and mutable to methods r=matklad a=Nashenas88 This adds a new `consuming` semantic modifier for syntax highlighters. This also emits `mutable` and `consuming` in two cases: - When a method takes `&mut self`, then it now has `function.mutable` emitted. - When a method takes `self`, and the type of `Self` is not `Copy`, then `function.consuming` is emitted. CC @flodiebold Co-authored-by: Paul Daniel Faria <[email protected]>
| * Add new method to Semantics, method_receiver_kind, which returns the kind of ↵Paul Daniel Faria2020-08-162-3/+45
| | | | | | | | | | | | | | self The options are Shared, Mutable, Consuming, and Copied. Use this to add proper highlighting to methods based on usage.
| * Mark mutating functions with `mutable` modifier, and owning functions with ↵Paul Daniel Faria2020-08-162-2/+17
| | | | | | | | `consuming`.
* | Merge remote-tracking branch 'rust-analyzer/master'Dmitry2020-08-184-45/+14
|\|
| * Don't expose hir::Path out of hirAleksey Kladov2020-08-154-45/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Conjecture: it's impossible to use hir::Path *correctly* from an IDE. I am not entirely sure about this, and we might need to add it back at some point, but I have to arguments that convince me that we probably won't: * `hir::Path` has to know about hygiene, which an IDE can't set up properly. * `hir::Path` lacks identity, but you actually have to know identity to resolve it correctly
* | synchronizing changesDmitry2020-08-141-1/+1
|/
* Rename hypothetical -> speculativeAleksey Kladov2020-08-141-5/+4
|
* Make hygiene private to hirAleksey Kladov2020-08-133-5/+26
|
* Rename ra_hir -> hirAleksey Kladov2020-08-1310-0/+3853