aboutsummaryrefslogtreecommitdiff
path: root/crates/hir/src
Commit message (Collapse)AuthorAgeFilesLines
* Create basic support for names case checks and implement function name case ↵Igor Aleksanov2020-10-121-0/+31
| | | | check
* Merge #5917bors[bot]2020-10-121-0/+17
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5917: Add a command to open docs for the symbol under the cursor r=matklad a=zacps #### Todo - [ ] Decide if there should be a default keybind or context menu entry - [x] Figure out how to get the documentation path for methods and other non-top-level defs - [x] Design the protocol extension. In future we'll probably want parameters for local/remote documentation URLs, so that should maybe be done in this PR? - [x] Code organisation - [x] Tests Co-authored-by: Zac Pullar-Strecker <[email protected]>
| * Remove methodowner & fix formattingZac Pullar-Strecker2020-10-082-40/+3
| |
| * Rebase fixesZac Pullar-Strecker2020-10-081-1/+1
| |
| * Change Option::Some bug to a fixme noteZac Pullar-Strecker2020-10-081-0/+1
| | | | | | | | IMO this is too much work to be worth fixing at the moment.
| * Differentiate method/tymethod by determining 'defaultness'Zac Pullar-Strecker2020-10-082-3/+10
| | | | | | | | | | | | | | | | | | Currently a method only has defaultness if it is a provided trait method, but this will change when specialisation is available and may need to become a concept known to hir. I opted to go for a 'fewest changes' approach given specialisation is still under development.
| * Code reorganisation and field supportZac Pullar-Strecker2020-10-081-1/+47
| |
* | Fix source_to_def for named enum variant fieldsJonas Schievink2020-10-091-0/+4
|/
* Shorten type hints for std::iter IteratorsLukas Wirth2020-10-062-3/+36
|
* Move ModPath->ast::Path function to IDE layerAleksey Kladov2020-10-061-5/+2
| | | | closes #6092
* Merge #6124bors[bot]2020-10-061-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | 6124: Better normalized crate name usage r=jonas-schievink a=SomeoneToIgnore Closes https://github.com/rust-analyzer/rust-analyzer/issues/5343 Closes https://github.com/rust-analyzer/rust-analyzer/issues/5932 Uses normalized name for code snippets (to be able to test the fix), hover messages and documentation rewrite links (are there any tests for those?). Also renamed the field to better resemble the semantics. Co-authored-by: Kirill Bulatov <[email protected]>
| * Properly name the fieldKirill Bulatov2020-10-021-2/+2
| |
| * Fix the hover dash issuesKirill Bulatov2020-10-021-2/+2
| |
* | Make ImportPrefix a configuration optionLukas Wirth2020-10-052-1/+3
| |
* | Make find_path_prefixed configurableLukas Wirth2020-10-051-1/+2
|/
* Minor clippy performance suggestionskjeremy2020-09-301-1/+1
|
* Don't unnecessarily unnest imports for import insertionLukas Wirth2020-09-251-0/+10
|
* 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-264-320/+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.
* 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-243-4/+351
|
* :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
|