rust/src/librustc_typeck
Corey Farwell 22e808a2fa Rollup merge of #45356 - neunenak:master, r=GuillaumeGomez
Add explanatory text for error E0599

Add a text description of this error instead of just example error code

r? GuillaumeGomez
2017-10-21 09:47:21 -04:00
..
check Auto merge of #45316 - goffrie:exitable-breakable-block, r=nikomatsakis 2017-10-20 05:24:04 +00:00
coherence Check namespaces when resolving associated items in typeck 2017-10-15 11:58:32 +01:00
outlives add a test case 2017-10-16 14:26:17 -04:00
variance incr.comp.: Add minimal version of try_mark_green procedure. 2017-10-02 15:36:47 +02:00
astconv.rs Check namespaces when resolving associated items in typeck 2017-10-15 11:58:32 +01:00
Cargo.toml rustc: expose monomorphic const_eval through on-demand. 2017-04-16 01:31:06 +03:00
check_unused.rs rustc: Remove HirId from queries 2017-09-11 07:53:48 -07:00
collect.rs create a seperate module for outlives. added a query for inferred_outlives. setup some files for upcoming tests 2017-10-16 14:26:11 -04:00
constrained_type_params.rs bring TyCtxt into scope 2017-09-14 21:26:06 -04:00
diagnostics.rs Add explanatory text for error E0599 2017-10-21 01:02:16 -07:00
impl_wf_check.rs Refactor lifetime name into an enum 2017-09-21 10:19:03 -07:00
lib.rs add a test case 2017-10-16 14:26:17 -04:00
namespace.rs Check namespaces when resolving associated items in typeck 2017-10-15 11:58:32 +01:00
README.md start writing some typeck docs (incomplete) 2017-09-19 10:39:00 -04:00

NB: This crate is part of the Rust compiler. For an overview of the compiler as a whole, see the README.md file found in librustc.

The rustc_typeck crate contains the source for "type collection" and "type checking", as well as a few other bits of related functionality. (It draws heavily on the type inferencing and trait solving code found in librustc.)

Type collection

Type "collection" is the process of convering the types found in the HIR (hir::Ty), which represent the syntactic things that the user wrote, into the internal representation used by the compiler (Ty<'tcx>) -- we also do similar conversions for where-clauses and other bits of the function signature.

To try and get a sense for the difference, consider this function:

struct Foo { }
fn foo(x: Foo, y: self::Foo) { .. }
//        ^^^     ^^^^^^^^^

Those two parameters x and y each have the same type: but they will have distinct hir::Ty nodes. Those nodes will have different spans, and of course they encode the path somewhat differently. But once they are "collected" into Ty<'tcx> nodes, they will be represented by the exact same internal type.

Collection is defined as a bundle of queries (e.g., type_of) for computing information about the various functions, traits, and other items in the crate being compiled. Note that each of these queries is concerned with interprocedural things -- for example, for a function definition, collection will figure out the type and signature of the function, but it will not visit the body of the function in any way, nor examine type annotations on local variables (that's the job of type checking).

For more details, see the collect module.

Type checking

TODO