aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAleksey Kladov <[email protected]>2019-01-19 19:53:57 +0000
committerAleksey Kladov <[email protected]>2019-01-21 08:27:01 +0000
commit11bdb7835ffa4a7a3ceee7cddb0ba4696fc652f4 (patch)
tree045e209f5361f3c86f2f2a863d2f704db0a614f8
parent43e7d80ec4ee340636ffabfa2c05ed24a725fa89 (diff)
write about type inference
-rw-r--r--guide.md29
1 files changed, 28 insertions, 1 deletions
diff --git a/guide.md b/guide.md
index d6a9057de..f8286f6fa 100644
--- a/guide.md
+++ b/guide.md
@@ -259,7 +259,11 @@ Java) there isn't a one-to-one mapping between source code and semantic model. A
259single function definition in the source code might result in several semantic 259single function definition in the source code might result in several semantic
260functions: for example, the same source file might be included as a module into 260functions: for example, the same source file might be included as a module into
261several crate, or a single "crate" might be present in the compilation DAG 261several crate, or a single "crate" might be present in the compilation DAG
262several times, with different sets of `cfg`s enabled. 262several times, with different sets of `cfg`s enabled. The IDE-specific task of
263mapping source code position into semantic model is inherently imprecise for
264this 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
264The semantic interface is declared in [`code_model_api`] module. Each entity is 268The semantic interface is declared in [`code_model_api`] module. Each entity is
265identified by integer id and has a bunch of methods which take a salsa database 269identified 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
494First of all, implementation of type inference in rust analyzer was spearheaded
495by [@flodiebold]. [#327] was an awesome Christmas present, thank you, Florian!
496
497Type inference runs on per-function granularity and uses the patterns we've
498discussed previously.
499
500First, we [lower ast] of function body into a position-independent
501representation. In this representation, each expression is assigned a
502[positional id]. Alongside the lowered expression, [a source map] is produced,
503which maps between expression ids and original syntax. This lowering step also
504deals with "incomplete" source trees by replacing missing expressions by an
505explicit `Missing` expression.
506
507Given the lower body of the function, we can now run [type inference] and
508construct 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