Replace uses of int/uint with isize/uzsize in doc examples

src/librustc/middle/infer/region_inference/mod.rs

@@ -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
 /// }
 /// ```

src/librustc/middle/liveness.rs

@@ -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 {

src/librustc_borrowck/borrowck/check_loans.rs

@@ -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 }

src/librustc_borrowck/borrowck/gather_loans/mod.rs

@@ -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
         //!     }
         //!

src/librustc_trans/trans/debuginfo/doc.rs

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

src/librustc_trans/trans/meth.rs

@@ -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 ...
 ///    }
 ///

src/librustc_typeck/check/regionck.rs

@@ -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)

src/librustc_typeck/variance.rs

@@ -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,25 +190,25 @@
 //! - 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`.
 //!
 //! 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.