bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

Convert gigantic comment away from //! form. It is annoying to

Browse source 
read (`//!` is intrusive) and annoying to edit (must maintain a prefix
on every line). Since the only purpose of a `doc.rs` file is to have a
bunch of text, using `/*!` and `*/` without indentations seems
appropriate.
This commit is contained in:
Niko Matsakis 2014-12-15 05:44:59 -05:00
parent f45c0ef51e
commit dab6e70e03
1 changed files with 402 additions and 396 deletions
Download patch file Download diff file Expand all files Collapse all files

798
src/librustc/middle/traits/doc.rs
View file

@ -8,399 +8,405 @@
// option. This file may not be copied, modified, or distributed // option. This file may not be copied, modified, or distributed
// except according to those terms. // except according to those terms.
//! # TRAIT RESOLUTION /*!
//!
//! This document describes the general process and points out some non-obvious # TRAIT RESOLUTION
//! things.
//! This document describes the general process and points out some non-obvious
//! ## Major concepts things.
//!
//! Trait resolution is the process of pairing up an impl with each ## Major concepts
//! reference to a trait. So, for example, if there is a generic function like:
//! Trait resolution is the process of pairing up an impl with each
//! fn clone_slice<T:Clone>(x: &[T]) -> Vec<T> { ... } reference to a trait. So, for example, if there is a generic function like:
//!
//! and then a call to that function: fn clone_slice<T:Clone>(x: &[T]) -> Vec<T> { ... }
//!
//! let v: Vec<int> = clone_slice([1, 2, 3].as_slice()) and then a call to that function:
//!
//! it is the job of trait resolution to figure out (in which case) let v: Vec<int> = clone_slice([1, 2, 3].as_slice())
//! whether there exists an impl of `int : Clone`
//! it is the job of trait resolution to figure out (in which case)
//! Note that in some cases, like generic functions, we may not be able to whether there exists an impl of `int : Clone`
//! find a specific impl, but we can figure out that the caller must
//! provide an impl. To see what I mean, consider the body of `clone_slice`: Note that in some cases, like generic functions, we may not be able to
//! find a specific impl, but we can figure out that the caller must
//! fn clone_slice<T:Clone>(x: &[T]) -> Vec<T> { provide an impl. To see what I mean, consider the body of `clone_slice`:
//! let mut v = Vec::new();
//! for e in x.iter() { fn clone_slice<T:Clone>(x: &[T]) -> Vec<T> {
//! v.push((*e).clone()); // (*) let mut v = Vec::new();
//! } for e in x.iter() {
//! } v.push((*e).clone()); // (*)
//! }
//! The line marked `(*)` is only legal if `T` (the type of `*e`) }
//! implements the `Clone` trait. Naturally, since we don't know what `T`
//! is, we can't find the specific impl; but based on the bound `T:Clone`, The line marked `(*)` is only legal if `T` (the type of `*e`)
//! we can say that there exists an impl which the caller must provide. implements the `Clone` trait. Naturally, since we don't know what `T`
//! is, we can't find the specific impl; but based on the bound `T:Clone`,
//! We use the term *obligation* to refer to a trait reference in need of we can say that there exists an impl which the caller must provide.
//! an impl.
//! We use the term *obligation* to refer to a trait reference in need of
//! ## Overview an impl.
//!
//! Trait resolution consists of three major parts: ## Overview
//!
//! - SELECTION: Deciding how to resolve a specific obligation. For Trait resolution consists of three major parts:
//! example, selection might decide that a specific obligation can be
//! resolved by employing an impl which matches the self type, or by - SELECTION: Deciding how to resolve a specific obligation. For
//! using a parameter bound. In the case of an impl, Selecting one example, selection might decide that a specific obligation can be
//! obligation can create *nested obligations* because of where clauses resolved by employing an impl which matches the self type, or by
//! on the impl itself. It may also require evaluating those nested using a parameter bound. In the case of an impl, Selecting one
//! obligations to resolve ambiguities. obligation can create *nested obligations* because of where clauses
//! on the impl itself. It may also require evaluating those nested
//! - FULFILLMENT: The fulfillment code is what tracks that obligations obligations to resolve ambiguities.
//! are completely fulfilled. Basically it is a worklist of obligations
//! to be selected: once selection is successful, the obligation is - FULFILLMENT: The fulfillment code is what tracks that obligations
//! removed from the worklist and any nested obligations are enqueued. are completely fulfilled. Basically it is a worklist of obligations
//! to be selected: once selection is successful, the obligation is
//! - COHERENCE: The coherence checks are intended to ensure that there removed from the worklist and any nested obligations are enqueued.
//! are never overlapping impls, where two impls could be used with
//! equal precedence. - COHERENCE: The coherence checks are intended to ensure that there
//! are never overlapping impls, where two impls could be used with
//! ## Selection equal precedence.
//!
//! Selection is the process of deciding whether an obligation can be ## Selection
//! resolved and, if so, how it is to be resolved (via impl, where clause, etc).
//! The main interface is the `select()` function, which takes an obligation Selection is the process of deciding whether an obligation can be
//! and returns a `SelectionResult`. There are three possible outcomes: resolved and, if so, how it is to be resolved (via impl, where clause, etc).
//! The main interface is the `select()` function, which takes an obligation
//! - `Ok(Some(selection))` -- yes, the obligation can be resolved, and and returns a `SelectionResult`. There are three possible outcomes:
//! `selection` indicates how. If the impl was resolved via an impl,
//! then `selection` may also indicate nested obligations that are required - `Ok(Some(selection))` -- yes, the obligation can be resolved, and
//! by the impl. `selection` indicates how. If the impl was resolved via an impl,
//! then `selection` may also indicate nested obligations that are required
//! - `Ok(None)` -- we are not yet sure whether the obligation can be by the impl.
//! resolved or not. This happens most commonly when the obligation
//! contains unbound type variables. - `Ok(None)` -- we are not yet sure whether the obligation can be
//! resolved or not. This happens most commonly when the obligation
//! - `Err(err)` -- the obligation definitely cannot be resolved due to a contains unbound type variables.
//! type error, or because there are no impls that could possibly apply,
//! etc. - `Err(err)` -- the obligation definitely cannot be resolved due to a
//! type error, or because there are no impls that could possibly apply,
//! The basic algorithm for selection is broken into two big phases: etc.
//! candidate assembly and confirmation.
//! The basic algorithm for selection is broken into two big phases:
//! ### Candidate assembly candidate assembly and confirmation.
//!
//! Searches for impls/where-clauses/etc that might ### Candidate assembly
//! possibly be used to satisfy the obligation. Each of those is called
//! a candidate. To avoid ambiguity, we want to find exactly one Searches for impls/where-clauses/etc that might
//! candidate that is definitively applicable. In some cases, we may not possibly be used to satisfy the obligation. Each of those is called
//! know whether an impl/where-clause applies or not -- this occurs when a candidate. To avoid ambiguity, we want to find exactly one
//! the obligation contains unbound inference variables. candidate that is definitively applicable. In some cases, we may not
//! know whether an impl/where-clause applies or not -- this occurs when
//! The basic idea for candidate assembly is to do a first pass in which the obligation contains unbound inference variables.
//! we identify all possible candidates. During this pass, all that we do
//! is try and unify the type parameters. (In particular, we ignore any The basic idea for candidate assembly is to do a first pass in which
//! nested where clauses.) Presuming that this unification succeeds, the we identify all possible candidates. During this pass, all that we do
//! impl is added as a candidate. is try and unify the type parameters. (In particular, we ignore any
//! nested where clauses.) Presuming that this unification succeeds, the
//! Once this first pass is done, we can examine the set of candidates. If impl is added as a candidate.
//! it is a singleton set, then we are done: this is the only impl in
//! scope that could possibly apply. Otherwise, we can winnow down the set Once this first pass is done, we can examine the set of candidates. If
//! of candidates by using where clauses and other conditions. If this it is a singleton set, then we are done: this is the only impl in
//! reduced set yields a single, unambiguous entry, we're good to go, scope that could possibly apply. Otherwise, we can winnow down the set
//! otherwise the result is considered ambiguous. of candidates by using where clauses and other conditions. If this
//! reduced set yields a single, unambiguous entry, we're good to go,
//! #### The basic process: Inferring based on the impls we see otherwise the result is considered ambiguous.
//!
//! This process is easier if we work through some examples. Consider #### The basic process: Inferring based on the impls we see
//! the following trait:
//! This process is easier if we work through some examples. Consider
//! ``` the following trait:
//! trait Convert<Target> {
//! fn convert(&self) -> Target; ```
//! } trait Convert<Target> {
//! ``` fn convert(&self) -> Target;
//! }
//! This trait just has one method. It's about as simple as it gets. It ```
//! converts from the (implicit) `Self` type to the `Target` type. If we
//! wanted to permit conversion between `int` and `uint`, we might This trait just has one method. It's about as simple as it gets. It
//! implement `Convert` like so: converts from the (implicit) `Self` type to the `Target` type. If we
//! wanted to permit conversion between `int` and `uint`, we might
//! ```rust implement `Convert` like so:
//! impl Convert<uint> for int { ... } // int -> uint
//! impl Convert<int> for uint { ... } // uint -> uint ```rust
//! ``` impl Convert<uint> for int { ... } // int -> uint
//! impl Convert<int> for uint { ... } // uint -> uint
//! Now imagine there is some code like the following: ```
//!
//! ```rust Now imagine there is some code like the following:
//! let x: int = ...;
//! let y = x.convert(); ```rust
//! ``` let x: int = ...;
//! let y = x.convert();
//! The call to convert will generate a trait reference `Convert<$Y> for ```
//! int`, where `$Y` is the type variable representing the type of
//! `y`. When we match this against the two impls we can see, we will find The call to convert will generate a trait reference `Convert<$Y> for
//! that only one remains: `Convert<uint> for int`. Therefore, we can int`, where `$Y` is the type variable representing the type of
//! select this impl, which will cause the type of `$Y` to be unified to `y`. When we match this against the two impls we can see, we will find
//! `uint`. (Note that while assembling candidates, we do the initial that only one remains: `Convert<uint> for int`. Therefore, we can
//! unifications in a transaction, so that they don't affect one another.) select this impl, which will cause the type of `$Y` to be unified to
//! `uint`. (Note that while assembling candidates, we do the initial
//! There are tests to this effect in src/test/run-pass: unifications in a transaction, so that they don't affect one another.)
//!
//! traits-multidispatch-infer-convert-source-and-target.rs There are tests to this effect in src/test/run-pass:
//! traits-multidispatch-infer-convert-target.rs
//! traits-multidispatch-infer-convert-source-and-target.rs
//! #### Winnowing: Resolving ambiguities traits-multidispatch-infer-convert-target.rs
//!
//! But what happens if there are multiple impls where all the types #### Winnowing: Resolving ambiguities
//! unify? Consider this example:
//! But what happens if there are multiple impls where all the types
//! ```rust unify? Consider this example:
//! trait Get {
//! fn get(&self) -> Self; ```rust
//! } trait Get {
//! fn get(&self) -> Self;
//! impl<T:Copy> Get for T { }
//! fn get(&self) -> T { *self }
//! } impl<T:Copy> Get for T {
//! fn get(&self) -> T { *self }
//! impl<T:Get> Get for Box<T> { }
//! fn get(&self) -> Box<T> { box get_it(&**self) }
//! } impl<T:Get> Get for Box<T> {
//! ``` fn get(&self) -> Box<T> { box get_it(&**self) }
//! }
//! What happens when we invoke `get_it(&box 1_u16)`, for example? In this ```
//! case, the `Self` type is `Box<u16>` -- that unifies with both impls,
//! because the first applies to all types, and the second to all What happens when we invoke `get_it(&box 1_u16)`, for example? In this
//! boxes. In the olden days we'd have called this ambiguous. But what we case, the `Self` type is `Box<u16>` -- that unifies with both impls,
//! do now is do a second *winnowing* pass that considers where clauses because the first applies to all types, and the second to all
//! and attempts to remove candidates -- in this case, the first impl only boxes. In the olden days we'd have called this ambiguous. But what we
//! applies if `Box<u16> : Copy`, which doesn't hold. After winnowing, do now is do a second *winnowing* pass that considers where clauses
//! then, we are left with just one candidate, so we can proceed. There is and attempts to remove candidates -- in this case, the first impl only
//! a test of this in `src/test/run-pass/traits-conditional-dispatch.rs`. applies if `Box<u16> : Copy`, which doesn't hold. After winnowing,
//! then, we are left with just one candidate, so we can proceed. There is
//! #### Matching a test of this in `src/test/run-pass/traits-conditional-dispatch.rs`.
//!
//! The subroutines that decide whether a particular impl/where-clause/etc #### Matching
//! applies to a particular obligation. At the moment, this amounts to
//! unifying the self types, but in the future we may also recursively The subroutines that decide whether a particular impl/where-clause/etc
//! consider some of the nested obligations, in the case of an impl. applies to a particular obligation. At the moment, this amounts to
//! unifying the self types, but in the future we may also recursively
//! #### Lifetimes and selection consider some of the nested obligations, in the case of an impl.
//!
//! Because of how that lifetime inference works, it is not possible to #### Lifetimes and selection
//! give back immediate feedback as to whether a unification or subtype
//! relationship between lifetimes holds or not. Therefore, lifetime Because of how that lifetime inference works, it is not possible to
//! matching is *not* considered during selection. This is reflected in give back immediate feedback as to whether a unification or subtype
//! the fact that subregion assignment is infallible. This may yield relationship between lifetimes holds or not. Therefore, lifetime
//! lifetime constraints that will later be found to be in error (in matching is *not* considered during selection. This is reflected in
//! contrast, the non-lifetime-constraints have already been checked the fact that subregion assignment is infallible. This may yield
//! during selection and can never cause an error, though naturally they lifetime constraints that will later be found to be in error (in
//! may lead to other errors downstream). contrast, the non-lifetime-constraints have already been checked
//! during selection and can never cause an error, though naturally they
//! #### Where clauses may lead to other errors downstream).
//!
//! Besides an impl, the other major way to resolve an obligation is via a #### Where clauses
//! where clause. The selection process is always given a *parameter
//! environment* which contains a list of where clauses, which are Besides an impl, the other major way to resolve an obligation is via a
//! basically obligations that can assume are satisfiable. We will iterate where clause. The selection process is always given a *parameter
//! over that list and check whether our current obligation can be found environment* which contains a list of where clauses, which are
//! in that list, and if so it is considered satisfied. More precisely, we basically obligations that can assume are satisfiable. We will iterate
//! want to check whether there is a where-clause obligation that is for over that list and check whether our current obligation can be found
//! the same trait (or some subtrait) and for which the self types match, in that list, and if so it is considered satisfied. More precisely, we
//! using the definition of *matching* given above. want to check whether there is a where-clause obligation that is for
//! the same trait (or some subtrait) and for which the self types match,
//! Consider this simple example: using the definition of *matching* given above.
//!
//! trait A1 { ... } Consider this simple example:
//! trait A2 : A1 { ... }
//! trait A1 { ... }
//! trait B { ... } trait A2 : A1 { ... }
//!
//! fn foo<X:A2+B> { ... } trait B { ... }
//!
//! Clearly we can use methods offered by `A1`, `A2`, or `B` within the fn foo<X:A2+B> { ... }
//! body of `foo`. In each case, that will incur an obligation like `X :
//! A1` or `X : A2`. The parameter environment will contain two Clearly we can use methods offered by `A1`, `A2`, or `B` within the
//! where-clauses, `X : A2` and `X : B`. For each obligation, then, we body of `foo`. In each case, that will incur an obligation like `X :
//! search this list of where-clauses. To resolve an obligation `X:A1`, A1` or `X : A2`. The parameter environment will contain two
//! we would note that `X:A2` implies that `X:A1`. where-clauses, `X : A2` and `X : B`. For each obligation, then, we
//! search this list of where-clauses. To resolve an obligation `X:A1`,
//! ### Confirmation we would note that `X:A2` implies that `X:A1`.
//!
//! Confirmation unifies the output type parameters of the trait with the ### Confirmation
//! values found in the obligation, possibly yielding a type error. If we
//! return to our example of the `Convert` trait from the previous Confirmation unifies the output type parameters of the trait with the
//! section, confirmation is where an error would be reported, because the values found in the obligation, possibly yielding a type error. If we
//! impl specified that `T` would be `uint`, but the obligation reported return to our example of the `Convert` trait from the previous
//! `char`. Hence the result of selection would be an error. section, confirmation is where an error would be reported, because the
//! impl specified that `T` would be `uint`, but the obligation reported
//! ### Selection during translation `char`. Hence the result of selection would be an error.
//!
//! During type checking, we do not store the results of trait selection. ### Selection during translation
//! We simply wish to verify that trait selection will succeed. Then
//! later, at trans time, when we have all concrete types available, we During type checking, we do not store the results of trait selection.
//! can repeat the trait selection. In this case, we do not consider any We simply wish to verify that trait selection will succeed. Then
//! where-clauses to be in scope. We know that therefore each resolution later, at trans time, when we have all concrete types available, we
//! will resolve to a particular impl. can repeat the trait selection. In this case, we do not consider any
//! where-clauses to be in scope. We know that therefore each resolution
//! One interesting twist has to do with nested obligations. In general, in trans, will resolve to a particular impl.
//! we only need to do a "shallow" selection for an obligation. That is, we wish to
//! identify which impl applies, but we do not (yet) need to decide how to select One interesting twist has to do with nested obligations. In general, in trans,
//! any nested obligations. Nonetheless, we *do* currently do a complete resolution, we only need to do a "shallow" selection for an obligation. That is, we wish to
//! and that is because it can sometimes inform the results of type inference. That is, identify which impl applies, but we do not (yet) need to decide how to select
//! we do not have the full substitutions in terms of the type varibales of the impl available any nested obligations. Nonetheless, we *do* currently do a complete resolution,
//! to us, so we must run trait selection to figure everything out. and that is because it can sometimes inform the results of type inference. That is,
//! we do not have the full substitutions in terms of the type varibales of the impl available
//! Here is an example: to us, so we must run trait selection to figure everything out.
//!
//! trait Foo { ... } Here is an example:
//! impl<U,T:Bar<U>> Foo for Vec<T> { ... }
//! trait Foo { ... }
//! impl Bar<uint> for int { ... } impl<U,T:Bar<U>> Foo for Vec<T> { ... }
//!
//! After one shallow round of selection for an obligation like `Vec<int> impl Bar<uint> for int { ... }
//! : Foo`, we would know which impl we want, and we would know that
//! `T=int`, but we do not know the type of `U`. We must select the After one shallow round of selection for an obligation like `Vec<int>
//! nested obligation `int : Bar<U>` to find out that `U=uint`. : Foo`, we would know which impl we want, and we would know that
//! `T=int`, but we do not know the type of `U`. We must select the
//! It would be good to only do *just as much* nested resolution as nested obligation `int : Bar<U>` to find out that `U=uint`.
//! necessary. Currently, though, we just do a full resolution.
//! It would be good to only do *just as much* nested resolution as
//! ## Method matching necessary. Currently, though, we just do a full resolution.
//!
//! Method dispach follows a slightly different path than normal trait ## Method matching
//! selection. This is because it must account for the transformed self
//! type of the receiver and various other complications. The procedure is Method dispach follows a slightly different path than normal trait
//! described in `select.rs` in the "METHOD MATCHING" section. selection. This is because it must account for the transformed self
//! type of the receiver and various other complications. The procedure is
//! # Caching and subtle considerations therewith described in `select.rs` in the "METHOD MATCHING" section.
//!
//! In general we attempt to cache the results of trait selection. This # Caching and subtle considerations therewith
//! is a somewhat complex process. Part of the reason for this is that we
//! want to be able to cache results even when all the types in the trait In general we attempt to cache the results of trait selection. This
//! reference are not fully known. In that case, it may happen that the is a somewhat complex process. Part of the reason for this is that we
//! trait selection process is also influencing type variables, so we have want to be able to cache results even when all the types in the trait
//! to be able to not only cache the *result* of the selection process, reference are not fully known. In that case, it may happen that the
//! but *replay* its effects on the type variables. trait selection process is also influencing type variables, so we have
//! to be able to not only cache the *result* of the selection process,
//! ## An example but *replay* its effects on the type variables.
//!
//! The high-level idea of how the cache works is that we first replace ## An example
//! all unbound inference variables with skolemized versions. Therefore,
//! if we had a trait reference `uint : Foo<$1>`, where `$n` is an unbound The high-level idea of how the cache works is that we first replace
//! inference variable, we might replace it with `uint : Foo<%0>`, where all unbound inference variables with skolemized versions. Therefore,
//! `%n` is a skolemized type. We would then look this up in the cache. if we had a trait reference `uint : Foo<$1>`, where `$n` is an unbound
//! If we found a hit, the hit would tell us the immediate next step to inference variable, we might replace it with `uint : Foo<%0>`, where
//! take in the selection process: i.e., apply impl #22, or apply where `%n` is a skolemized type. We would then look this up in the cache.
//! clause `X : Foo<Y>`. Let's say in this case there is no hit. If we found a hit, the hit would tell us the immediate next step to
//! Therefore, we search through impls and where clauses and so forth, and take in the selection process: i.e., apply impl #22, or apply where
//! we come to the conclusion that the only possible impl is this one, clause `X : Foo<Y>`. Let's say in this case there is no hit.
//! with def-id 22: Therefore, we search through impls and where clauses and so forth, and
//! we come to the conclusion that the only possible impl is this one,
//! impl Foo<int> for uint { ... } // Impl #22 with def-id 22:
//!
//! We would then record in the cache `uint : Foo<%0> ==> impl Foo<int> for uint { ... } // Impl #22
//! ImplCandidate(22)`. Next we would confirm `ImplCandidate(22)`, which
//! would (as a side-effect) unify `$1` with `int`. We would then record in the cache `uint : Foo<%0> ==>
//! ImplCandidate(22)`. Next we would confirm `ImplCandidate(22)`, which
//! Now, at some later time, we might come along and see a `uint : would (as a side-effect) unify `$1` with `int`.
//! Foo<$3>`. When skolemized, this would yield `uint : Foo<%0>`, just as
//! before, and hence the cache lookup would succeed, yielding Now, at some later time, we might come along and see a `uint :
//! `ImplCandidate(22)`. We would confirm `ImplCandidate(22)` which would Foo<$3>`. When skolemized, this would yield `uint : Foo<%0>`, just as
//! (as a side-effect) unify `$3` with `int`. before, and hence the cache lookup would succeed, yielding
//! `ImplCandidate(22)`. We would confirm `ImplCandidate(22)` which would
//! ## Where clauses and the local vs global cache (as a side-effect) unify `$3` with `int`.
//!
//! One subtle interaction is that the results of trait lookup will vary ## Where clauses and the local vs global cache
//! depending on what where clauses are in scope. Therefore, we actually
//! have *two* caches, a local and a global cache. The local cache is One subtle interaction is that the results of trait lookup will vary
//! attached to the `ParameterEnvironment` and the global cache attached depending on what where clauses are in scope. Therefore, we actually
//! to the `tcx`. We use the local cache whenever the result might depend have *two* caches, a local and a global cache. The local cache is
//! on the where clauses that are in scope. The determination of which attached to the `ParameterEnvironment` and the global cache attached
//! cache to use is done by the method `pick_candidate_cache` in to the `tcx`. We use the local cache whenever the result might depend
//! `select.rs`. on the where clauses that are in scope. The determination of which
//! cache to use is done by the method `pick_candidate_cache` in
//! There are two cases where we currently use the local cache. The `select.rs`.
//! current rules are probably more conservative than necessary.
//! There are two cases where we currently use the local cache. The
//! ### Trait references that involve parameter types current rules are probably more conservative than necessary.
//!
//! The most obvious case where you need the local environment is ### Trait references that involve parameter types
//! when the trait reference includes parameter types. For example,
//! consider the following function: The most obvious case where you need the local environment is
//! when the trait reference includes parameter types. For example,
//! impl<T> Vec<T> { consider the following function:
//! fn foo(x: T)
//! where T : Foo impl<T> Vec<T> {
//! { ... } fn foo(x: T)
//! where T : Foo
//! fn bar(x: T) { ... }
//! { ... }
//! } fn bar(x: T)
//! { ... }
//! If there is an obligation `T : Foo`, or `int : Bar<T>`, or whatever, }
//! clearly the results from `foo` and `bar` are potentially different,
//! since the set of where clauses in scope are different. If there is an obligation `T : Foo`, or `int : Bar<T>`, or whatever,
//! clearly the results from `foo` and `bar` are potentially different,
//! ### Trait references with unbound variables when where clauses are in scope since the set of where clauses in scope are different.
//!
//! There is another less obvious interaction which involves unbound variables ### Trait references with unbound variables when where clauses are in scope
//! where *only* where clauses are in scope (no impls). This manifested as
//! issue #18209 (`run-pass/trait-cache-issue-18209.rs`). Consider There is another less obvious interaction which involves unbound variables
//! this snippet: where *only* where clauses are in scope (no impls). This manifested as
//! issue #18209 (`run-pass/trait-cache-issue-18209.rs`). Consider
//! ``` this snippet:
//! pub trait Foo {
//! fn load_from() -> Box<Self>; ```
//! fn load() -> Box<Self> { pub trait Foo {
//! Foo::load_from() fn load_from() -> Box<Self>;
//! } fn load() -> Box<Self> {
//! } Foo::load_from()
//! ``` }
//! }
//! The default method will incur an obligation `$0 : Foo` from the call ```
//! to `load_from`. If there are no impls, this can be eagerly resolved to
//! `VtableParam(Self : Foo)` and cached. Because the trait reference The default method will incur an obligation `$0 : Foo` from the call
//! doesn't involve any parameters types (only the resolution does), this to `load_from`. If there are no impls, this can be eagerly resolved to
//! result was stored in the global cache, causing later calls to `VtableParam(Self : Foo)` and cached. Because the trait reference
//! `Foo::load_from()` to get nonsense. doesn't involve any parameters types (only the resolution does), this
//! result was stored in the global cache, causing later calls to
//! To fix this, we always use the local cache if there are unbound `Foo::load_from()` to get nonsense.
//! variables and where clauses in scope. This is more conservative than
//! necessary as far as I can tell. However, it still seems to be a simple To fix this, we always use the local cache if there are unbound
//! rule and I observe ~99% hit rate on rustc, so it doesn't seem to hurt variables and where clauses in scope. This is more conservative than
//! us in particular. necessary as far as I can tell. However, it still seems to be a simple
//! rule and I observe ~99% hit rate on rustc, so it doesn't seem to hurt
//! Here is an example of the kind of subtle case that I would be worried us in particular.
//! about with a more complex rule (although this particular case works
//! out ok). Imagine the trait reference doesn't directly reference a Here is an example of the kind of subtle case that I would be worried
//! where clause, but the where clause plays a role in the winnowing about with a more complex rule (although this particular case works
//! phase. Something like this: out ok). Imagine the trait reference doesn't directly reference a
//! where clause, but the where clause plays a role in the winnowing
//! ``` phase. Something like this:
//! pub trait Foo<T> { ... }
//! pub trait Bar { ... } ```
//! impl<U,T:Bar> Foo<U> for T { ... } // Impl A pub trait Foo<T> { ... }
//! impl Foo<char> for uint { ... } // Impl B pub trait Bar { ... }
//! ``` impl<U,T:Bar> Foo<U> for T { ... } // Impl A
//! impl Foo<char> for uint { ... } // Impl B
//! Now, in some function, we have no where clauses in scope, and we have ```
//! an obligation `$1 : Foo<$0>`. We might then conclude that `$0=char`
//! and `$1=uint`: this is because for impl A to apply, `uint:Bar` would Now, in some function, we have no where clauses in scope, and we have
//! have to hold, and we know it does not or else the coherence check an obligation `$1 : Foo<$0>`. We might then conclude that `$0=char`
//! would have failed. So we might enter into our global cache: `$1 : and `$1=uint`: this is because for impl A to apply, `uint:Bar` would
//! Foo<$0> => Impl B`. Then we come along in a different scope, where a have to hold, and we know it does not or else the coherence check
//! generic type `A` is around with the bound `A:Bar`. Now suddenly the would have failed. So we might enter into our global cache: `$1 :
//! impl is viable. Foo<$0> => Impl B`. Then we come along in a different scope, where a
//! generic type `A` is around with the bound `A:Bar`. Now suddenly the
//! The flaw in this imaginary DOOMSDAY SCENARIO is that we would not impl is viable.
//! currently conclude that `$1 : Foo<$0>` implies that `$0 == uint` and
//! `$1 == char`, even though it is true that (absent type parameters) The flaw in this imaginary DOOMSDAY SCENARIO is that we would not
//! there is no other type the user could enter. However, it is not currently conclude that `$1 : Foo<$0>` implies that `$0 == uint` and
//! *completely* implausible that we *could* draw this conclusion in the `$1 == char`, even though it is true that (absent type parameters)
//! future; we wouldn't have to guess types, in particular, we could be there is no other type the user could enter. However, it is not
//! led by the impls. *completely* implausible that we *could* draw this conclusion in the
future; we wouldn't have to guess types, in particular, we could be
led by the impls.
*/