Rollup merge of #30136 - fhahn:remove-int-from-doc-examples, r=steveklabnik

This PR replaces uses of int/uint in some doc examples in various crates.
This commit is contained in:
Steve Klabnik 2015-12-01 19:01:41 -05:00
commit 8fd7f1e614
8 changed files with 22 additions and 20 deletions

View File

@ -159,8 +159,8 @@ pub enum RegionResolutionError<'tcx> {
/// like to indicate so to the user.
/// For example, the following function
/// ```
/// struct Foo { bar: int }
/// fn foo2<'a, 'b>(x: &'a Foo) -> &'b int {
/// struct Foo { bar: isize }
/// fn foo2<'a, 'b>(x: &'a Foo) -> &'b isize {
/// &x.bar
/// }
/// ```

View File

@ -1583,7 +1583,7 @@ impl<'a, 'tcx> Liveness<'a, 'tcx> {
let r = self.should_warn(var);
if let Some(name) = r {
// annoying: for parameters in funcs like `fn(x: int)
// annoying: for parameters in funcs like `fn(x: isize)
// {ret}`, there is only one node, so asking about
// assigned_on_exit() is not meaningful.
let is_assigned = if ln == self.s.exit_ln {

View File

@ -718,8 +718,8 @@ impl<'a, 'tcx> CheckLoanCtxt<'a, 'tcx> {
///
/// For example:
///
/// ```
/// let a: int;
/// ```ignore
/// let a: isize;
/// a = 10; // ok, even though a is uninitialized
///
/// struct Point { x: usize, y: usize }

View File

@ -486,7 +486,9 @@ impl<'a, 'tcx> GatherLoanCtxt<'a, 'tcx> {
//! come about when variables of `&mut` type are re-borrowed,
//! as in this example:
//!
//! fn counter<'a>(v: &'a mut Foo) -> &'a mut uint {
//! struct Foo { counter: usize }
//!
//! fn counter<'a>(v: &'a mut Foo) -> &'a mut usize {
//! &mut v.counter
//! }
//!

View File

@ -66,7 +66,7 @@
//!
//! ```
//! struct List {
//! value: int,
//! value: isize,
//! tail: Option<Box<List>>,
//! }
//! ```

View File

@ -456,7 +456,7 @@ fn trans_trait_callee_from_llval<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
/// Generate a shim function that allows an object type like `SomeTrait` to
/// implement the type `SomeTrait`. Imagine a trait definition:
///
/// trait SomeTrait { fn get(&self) -> int; ... }
/// trait SomeTrait { fn get(&self) -> isize; ... }
///
/// And a generic bit of code:
///
@ -468,7 +468,7 @@ fn trans_trait_callee_from_llval<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
/// What is the value of `x` when `foo` is invoked with `T=SomeTrait`?
/// The answer is that it is a shim function generated by this routine:
///
/// fn shim(t: &SomeTrait) -> int {
/// fn shim(t: &SomeTrait) -> isize {
/// // ... call t.get() virtually ...
/// }
///

View File

@ -59,7 +59,7 @@
//! There are a number of troublesome scenarios in the tests
//! `region-dependent-*.rs`, but here is one example:
//!
//! struct Foo { i: int }
//! struct Foo { i: isize }
//! struct Bar { foo: Foo }
//! fn get_i(x: &'a Bar) -> &'a int {
//! let foo = &x.foo; // Lifetime L1
@ -233,8 +233,8 @@ impl<'a, 'tcx> Rcx<'a, 'tcx> {
/// Consider this silly example:
///
/// ```
/// fn borrow(x: &int) -> &int {x}
/// fn foo(x: @int) -> int { // block: B
/// fn borrow(x: &int) -> &isize {x}
/// fn foo(x: @int) -> isize { // block: B
/// let b = borrow(x); // region: <R0>
/// *b
/// }
@ -243,7 +243,7 @@ impl<'a, 'tcx> Rcx<'a, 'tcx> {
/// Here, the region of `b` will be `<R0>`. `<R0>` is constrained to be some subregion of the
/// block B and some superregion of the call. If we forced it now, we'd choose the smaller
/// region (the call). But that would make the *b illegal. Since we don't resolve, the type
/// of b will be `&<R0>.int` and then `*b` will require that `<R0>` be bigger than the let and
/// of b will be `&<R0>.isize` and then `*b` will require that `<R0>` be bigger than the let and
/// the `*b` expression, so we will effectively resolve `<R0>` to be the block B.
pub fn resolve_type(&self, unresolved_ty: Ty<'tcx>) -> Ty<'tcx> {
self.fcx.infcx().resolve_type_vars_if_possible(&unresolved_ty)

View File

@ -172,14 +172,14 @@
//!
//! Now imagine that I have an implementation of `ConvertTo` for `Object`:
//!
//! impl ConvertTo<int> for Object { ... }
//! impl ConvertTo<isize> for Object { ... }
//!
//! And I want to call `convertAll` on an array of strings. Suppose
//! further that for whatever reason I specifically supply the value of
//! `String` for the type parameter `T`:
//!
//! let mut vector = vec!["string", ...];
//! convertAll::<int, String>(vector);
//! convertAll::<isize, String>(vector);
//!
//! Is this legal? To put another way, can we apply the `impl` for
//! `Object` to the type `String`? The answer is yes, but to see why
@ -190,7 +190,7 @@
//! - It will then call the impl of `convertTo()` that is intended
//! for use with objects. This has the type:
//!
//! fn(self: &Object) -> int
//! fn(self: &Object) -> isize
//!
//! It is ok to provide a value for `self` of type `&String` because
//! `&String <: &Object`.
@ -198,17 +198,17 @@
//! OK, so intuitively we want this to be legal, so let's bring this back
//! to variance and see whether we are computing the correct result. We
//! must first figure out how to phrase the question "is an impl for
//! `Object,int` usable where an impl for `String,int` is expected?"
//! `Object,isize` usable where an impl for `String,isize` is expected?"
//!
//! Maybe it's helpful to think of a dictionary-passing implementation of
//! type classes. In that case, `convertAll()` takes an implicit parameter
//! representing the impl. In short, we *have* an impl of type:
//!
//! V_O = ConvertTo<int> for Object
//! V_O = ConvertTo<isize> for Object
//!
//! and the function prototype expects an impl of type:
//!
//! V_S = ConvertTo<int> for String
//! V_S = ConvertTo<isize> for String
//!
//! As with any argument, this is legal if the type of the value given
//! (`V_O`) is a subtype of the type expected (`V_S`). So is `V_O <: V_S`?
@ -217,7 +217,7 @@
//! covariant, it means that:
//!
//! V_O <: V_S iff
//! int <: int
//! isize <: isize
//! String <: Object
//!
//! These conditions are satisfied and so we are happy.