diff options
-rw-r--r-- | guide.md | 29 |
1 files changed, 28 insertions, 1 deletions
@@ -259,7 +259,11 @@ Java) there isn't a one-to-one mapping between source code and semantic model. A | |||
259 | single function definition in the source code might result in several semantic | 259 | single function definition in the source code might result in several semantic |
260 | functions: for example, the same source file might be included as a module into | 260 | functions: for example, the same source file might be included as a module into |
261 | several crate, or a single "crate" might be present in the compilation DAG | 261 | several crate, or a single "crate" might be present in the compilation DAG |
262 | several times, with different sets of `cfg`s enabled. | 262 | several times, with different sets of `cfg`s enabled. The IDE-specific task of |
263 | mapping source code position into semantic model is inherently imprecise for | ||
264 | this reason, and is handled by the [`source_binder`]. | ||
265 | |||
266 | [`source_binder`]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/source_binder.rs | ||
263 | 267 | ||
264 | The semantic interface is declared in [`code_model_api`] module. Each entity is | 268 | The semantic interface is declared in [`code_model_api`] module. Each entity is |
265 | identified by integer id and has a bunch of methods which take a salsa database | 269 | identified by integer id and has a bunch of methods which take a salsa database |
@@ -487,4 +491,27 @@ Naturally, name resolution [uses] this stable projection query. | |||
487 | 491 | ||
488 | ## Type inference | 492 | ## Type inference |
489 | 493 | ||
494 | First of all, implementation of type inference in rust analyzer was spearheaded | ||
495 | by [@flodiebold]. [#327] was an awesome Christmas present, thank you, Florian! | ||
496 | |||
497 | Type inference runs on per-function granularity and uses the patterns we've | ||
498 | discussed previously. | ||
499 | |||
500 | First, we [lower ast] of function body into a position-independent | ||
501 | representation. In this representation, each expression is assigned a | ||
502 | [positional id]. Alongside the lowered expression, [a source map] is produced, | ||
503 | which maps between expression ids and original syntax. This lowering step also | ||
504 | deals with "incomplete" source trees by replacing missing expressions by an | ||
505 | explicit `Missing` expression. | ||
506 | |||
507 | Given the lower body of the function, we can now run [type inference] and | ||
508 | construct a mapping from `ExprId`s to types. | ||
509 | |||
510 | [@flodiebold]: https://github.com/flodiebold | ||
511 | [#327]: https://github.com/rust-analyzer/rust-analyzer/pull/327 | ||
512 | [lower ast]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/expr.rs | ||
513 | [positional id]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/expr.rs#L13-L15 | ||
514 | [a source map]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/expr.rs#L41-L44 | ||
515 | [type-inference]: https://github.com/rust-analyzer/rust-analyzer/blob/guide-2019-01/crates/ra_hir/src/ty.rs#L1208-L1223 | ||
516 | |||
490 | ## Tying it all together: completion | 517 | ## Tying it all together: completion |