Auto merge of #30180 - tbu-:pr_isize_to_i32, r=arielb1

s/isize/i32

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: isize }
+/// struct Foo { bar: i32 }
-/// fn foo2<'a, 'b>(x: &'a Foo) -> &'b isize {
+/// fn foo2<'a, 'b>(x: &'a Foo) -> &'b i32 {
 ///    &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: isize)
+                // annoying: for parameters in funcs like `fn(x: i32)
                 // {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

@@ -719,10 +719,10 @@ impl<'a, 'tcx> CheckLoanCtxt<'a, 'tcx> {
     /// For example:
     ///
     /// ```ignore
-    /// let a: isize;
+    /// let a: i32;
     /// a = 10; // ok, even though a is uninitialized
     ///
-    /// struct Point { x: usize, y: usize }
+    /// struct Point { x: u32, y: u32 }
     /// let p: Point;
     /// p.x = 22; // ok, even though `p` is uninitialized
     ///

src/librustc_borrowck/borrowck/gather_loans/mod.rs

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

src/librustc_trans/trans/debuginfo/doc.rs

@@ -66,7 +66,7 @@
 //!
 //! ```
 //! struct List {
-//!     value: isize,
+//!     value: i32,
 //!     tail: Option<Box<List>>,
 //! }
 //! ```
@@ -75,7 +75,7 @@
 //!
 //! ```
 //! describe(t = List)
-//!   describe(t = int)
+//!   describe(t = i32)
 //!   describe(t = Option<Box<List>>)
 //!     describe(t = Box<List>)
 //!       describe(t = List) // at the beginning again...
@@ -166,7 +166,7 @@
 //!
 //! (3) Tuple-, pointer and function types are structurally identified, which
 //!     means that they are equivalent if their component types are equivalent
-//!     (i.e. (int, int) is the same regardless in which crate it is used).
+//!     (i.e. (i32, i32) is the same regardless in which crate it is used).
 //!
 //! This algorithm also provides a stable ID for types that are defined in one
 //! crate but instantiated from metadata within another crate. We just have to

src/librustc_trans/trans/meth.rs

@@ -182,17 +182,17 @@ pub fn trans_static_method_callee<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>,
     //         fn from<U:Foo>(n: U) -> Option<Self>;
     //     }
     //     ...
-    //     let f = <Vec<int> as Convert>::from::<String>(...)
+    //     let f = <Vec<i32> as Convert>::from::<String>(...)
     //
     // Here, in this call, which I've written with explicit UFCS
     // notation, the set of type parameters will be:
     //
     //     rcvr_type: [] <-- nothing declared on the trait itself
-    //     rcvr_self: [Vec<int>] <-- the self type
+    //     rcvr_self: [Vec<i32>] <-- the self type
     //     rcvr_method: [String] <-- method type parameter
     //
     // So we create a trait reference using the first two,
-    // basically corresponding to `<Vec<int> as Convert>`.
+    // basically corresponding to `<Vec<i32> as Convert>`.
     // The remaining type parameters (`rcvr_method`) will be used below.
     let trait_substs =
         Substs::erased(VecPerParamSpace::new(rcvr_type,
@@ -223,13 +223,13 @@ pub fn trans_static_method_callee<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>,
             //        fn from<U:Foo>(n: U) { ... }
             //    }
             //
-            // Recall that we matched `<Vec<int> as Convert>`. Trait
+            // Recall that we matched `<Vec<i32> as Convert>`. Trait
             // resolution will have given us a substitution
-            // containing `impl_substs=[[T=int],[],[]]` (the type
+            // containing `impl_substs=[[T=i32],[],[]]` (the type
             // parameters defined on the impl). We combine
             // that with the `rcvr_method` from before, which tells us
             // the type parameters from the *method*, to yield
-            // `callee_substs=[[T=int],[],[U=String]]`.
+            // `callee_substs=[[T=i32],[],[U=String]]`.
             let subst::SeparateVecsPerParamSpace {
                 types: impl_type,
                 selfs: impl_self,
@@ -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) -> isize; ... }
+///    trait SomeTrait { fn get(&self) -> i32; ... }
 ///
 /// 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) -> isize {
+///    fn shim(t: &SomeTrait) -> i32 {
 ///        // ... call t.get() virtually ...
 ///    }
 ///

src/librustc_typeck/check/regionck.rs

@@ -59,9 +59,9 @@
 //! There are a number of troublesome scenarios in the tests
 //! `region-dependent-*.rs`, but here is one example:
 //!
-//!     struct Foo { i: isize }
+//!     struct Foo { i: i32 }
 //!     struct Bar { foo: Foo  }
-//!     fn get_i(x: &'a Bar) -> &'a int {
+//!     fn get_i(x: &'a Bar) -> &'a i32 {
 //!        let foo = &x.foo; // Lifetime L1
 //!        &foo.i            // Lifetime L2
 //!     }
@@ -233,8 +233,8 @@ impl<'a, 'tcx> Rcx<'a, 'tcx> {
     /// Consider this silly example:
     ///
     /// ```
-    /// fn borrow(x: &int) -> &isize {x}
+    /// fn borrow(x: &i32) -> &i32 {x}
-    /// fn foo(x: @int) -> isize {  // block: B
+    /// fn foo(x: @i32) -> i32 {  // 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>.isize` and then `*b` will require that `<R0>` be bigger than the let and
+    /// of b will be `&<R0>.i32` 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<isize> for Object { ... }
+//!     impl ConvertTo<i32> 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::<isize, String>(vector);
+//!     convertAll::<i32, 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) -> isize
+//!       fn(self: &Object) -> i32
 //!
 //!   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,isize` usable where an impl for `String,isize` is expected?"
+//! `Object,i32` usable where an impl for `String,i32` 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<isize> for Object
+//!     V_O = ConvertTo<i32> for Object
 //!
 //! and the function prototype expects an impl of type:
 //!
-//!     V_S = ConvertTo<isize> for String
+//!     V_S = ConvertTo<i32> 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
-//!         isize <: isize
+//!         i32 <: i32
 //!         String <: Object
 //!
 //! These conditions are satisfied and so we are happy.