Skip to content

Commit f016b77

Browse files
committed
Auto merge of #30180 - tbu-:pr_isize_to_i32, r=arielb1
s/isize/i32
2 parents f5150dd + 57dad53 commit f016b77

File tree

8 files changed

+30
-30
lines changed

8 files changed

+30
-30
lines changed

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

+2-2
Original file line numberDiff line numberDiff line change
@@ -159,8 +159,8 @@ pub enum RegionResolutionError<'tcx> {
159159
/// like to indicate so to the user.
160160
/// For example, the following function
161161
/// ```
162-
/// struct Foo { bar: isize }
163-
/// fn foo2<'a, 'b>(x: &'a Foo) -> &'b isize {
162+
/// struct Foo { bar: i32 }
163+
/// fn foo2<'a, 'b>(x: &'a Foo) -> &'b i32 {
164164
/// &x.bar
165165
/// }
166166
/// ```

src/librustc/middle/liveness.rs

+1-1
Original file line numberDiff line numberDiff line change
@@ -1583,7 +1583,7 @@ impl<'a, 'tcx> Liveness<'a, 'tcx> {
15831583
let r = self.should_warn(var);
15841584
if let Some(name) = r {
15851585

1586-
// annoying: for parameters in funcs like `fn(x: isize)
1586+
// annoying: for parameters in funcs like `fn(x: i32)
15871587
// {ret}`, there is only one node, so asking about
15881588
// assigned_on_exit() is not meaningful.
15891589
let is_assigned = if ln == self.s.exit_ln {

src/librustc_borrowck/borrowck/check_loans.rs

+2-2
Original file line numberDiff line numberDiff line change
@@ -719,10 +719,10 @@ impl<'a, 'tcx> CheckLoanCtxt<'a, 'tcx> {
719719
/// For example:
720720
///
721721
/// ```ignore
722-
/// let a: isize;
722+
/// let a: i32;
723723
/// a = 10; // ok, even though a is uninitialized
724724
///
725-
/// struct Point { x: usize, y: usize }
725+
/// struct Point { x: u32, y: u32 }
726726
/// let p: Point;
727727
/// p.x = 22; // ok, even though `p` is uninitialized
728728
///

src/librustc_borrowck/borrowck/gather_loans/mod.rs

+2-2
Original file line numberDiff line numberDiff line change
@@ -486,9 +486,9 @@ impl<'a, 'tcx> GatherLoanCtxt<'a, 'tcx> {
486486
//! come about when variables of `&mut` type are re-borrowed,
487487
//! as in this example:
488488
//!
489-
//! struct Foo { counter: usize }
489+
//! struct Foo { counter: u32 }
490490
//!
491-
//! fn counter<'a>(v: &'a mut Foo) -> &'a mut usize {
491+
//! fn counter<'a>(v: &'a mut Foo) -> &'a mut u32 {
492492
//! &mut v.counter
493493
//! }
494494
//!

src/librustc_trans/trans/debuginfo/doc.rs

+3-3
Original file line numberDiff line numberDiff line change
@@ -66,7 +66,7 @@
6666
//!
6767
//! ```
6868
//! struct List {
69-
//! value: isize,
69+
//! value: i32,
7070
//! tail: Option<Box<List>>,
7171
//! }
7272
//! ```
@@ -75,7 +75,7 @@
7575
//!
7676
//! ```
7777
//! describe(t = List)
78-
//! describe(t = int)
78+
//! describe(t = i32)
7979
//! describe(t = Option<Box<List>>)
8080
//! describe(t = Box<List>)
8181
//! describe(t = List) // at the beginning again...
@@ -166,7 +166,7 @@
166166
//!
167167
//! (3) Tuple-, pointer and function types are structurally identified, which
168168
//! means that they are equivalent if their component types are equivalent
169-
//! (i.e. (int, int) is the same regardless in which crate it is used).
169+
//! (i.e. (i32, i32) is the same regardless in which crate it is used).
170170
//!
171171
//! This algorithm also provides a stable ID for types that are defined in one
172172
//! crate but instantiated from metadata within another crate. We just have to

src/librustc_trans/trans/meth.rs

+8-8
Original file line numberDiff line numberDiff line change
@@ -182,17 +182,17 @@ pub fn trans_static_method_callee<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>,
182182
// fn from<U:Foo>(n: U) -> Option<Self>;
183183
// }
184184
// ...
185-
// let f = <Vec<int> as Convert>::from::<String>(...)
185+
// let f = <Vec<i32> as Convert>::from::<String>(...)
186186
//
187187
// Here, in this call, which I've written with explicit UFCS
188188
// notation, the set of type parameters will be:
189189
//
190190
// rcvr_type: [] <-- nothing declared on the trait itself
191-
// rcvr_self: [Vec<int>] <-- the self type
191+
// rcvr_self: [Vec<i32>] <-- the self type
192192
// rcvr_method: [String] <-- method type parameter
193193
//
194194
// So we create a trait reference using the first two,
195-
// basically corresponding to `<Vec<int> as Convert>`.
195+
// basically corresponding to `<Vec<i32> as Convert>`.
196196
// The remaining type parameters (`rcvr_method`) will be used below.
197197
let trait_substs =
198198
Substs::erased(VecPerParamSpace::new(rcvr_type,
@@ -223,13 +223,13 @@ pub fn trans_static_method_callee<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>,
223223
// fn from<U:Foo>(n: U) { ... }
224224
// }
225225
//
226-
// Recall that we matched `<Vec<int> as Convert>`. Trait
226+
// Recall that we matched `<Vec<i32> as Convert>`. Trait
227227
// resolution will have given us a substitution
228-
// containing `impl_substs=[[T=int],[],[]]` (the type
228+
// containing `impl_substs=[[T=i32],[],[]]` (the type
229229
// parameters defined on the impl). We combine
230230
// that with the `rcvr_method` from before, which tells us
231231
// the type parameters from the *method*, to yield
232-
// `callee_substs=[[T=int],[],[U=String]]`.
232+
// `callee_substs=[[T=i32],[],[U=String]]`.
233233
let subst::SeparateVecsPerParamSpace {
234234
types: impl_type,
235235
selfs: impl_self,
@@ -456,7 +456,7 @@ fn trans_trait_callee_from_llval<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
456456
/// Generate a shim function that allows an object type like `SomeTrait` to
457457
/// implement the type `SomeTrait`. Imagine a trait definition:
458458
///
459-
/// trait SomeTrait { fn get(&self) -> isize; ... }
459+
/// trait SomeTrait { fn get(&self) -> i32; ... }
460460
///
461461
/// And a generic bit of code:
462462
///
@@ -468,7 +468,7 @@ fn trans_trait_callee_from_llval<'blk, 'tcx>(bcx: Block<'blk, 'tcx>,
468468
/// What is the value of `x` when `foo` is invoked with `T=SomeTrait`?
469469
/// The answer is that it is a shim function generated by this routine:
470470
///
471-
/// fn shim(t: &SomeTrait) -> isize {
471+
/// fn shim(t: &SomeTrait) -> i32 {
472472
/// // ... call t.get() virtually ...
473473
/// }
474474
///

src/librustc_typeck/check/regionck.rs

+5-5
Original file line numberDiff line numberDiff line change
@@ -59,9 +59,9 @@
5959
//! There are a number of troublesome scenarios in the tests
6060
//! `region-dependent-*.rs`, but here is one example:
6161
//!
62-
//! struct Foo { i: isize }
62+
//! struct Foo { i: i32 }
6363
//! struct Bar { foo: Foo }
64-
//! fn get_i(x: &'a Bar) -> &'a int {
64+
//! fn get_i(x: &'a Bar) -> &'a i32 {
6565
//! let foo = &x.foo; // Lifetime L1
6666
//! &foo.i // Lifetime L2
6767
//! }
@@ -233,8 +233,8 @@ impl<'a, 'tcx> Rcx<'a, 'tcx> {
233233
/// Consider this silly example:
234234
///
235235
/// ```
236-
/// fn borrow(x: &int) -> &isize {x}
237-
/// fn foo(x: @int) -> isize { // block: B
236+
/// fn borrow(x: &i32) -> &i32 {x}
237+
/// fn foo(x: @i32) -> i32 { // block: B
238238
/// let b = borrow(x); // region: <R0>
239239
/// *b
240240
/// }
@@ -243,7 +243,7 @@ impl<'a, 'tcx> Rcx<'a, 'tcx> {
243243
/// Here, the region of `b` will be `<R0>`. `<R0>` is constrained to be some subregion of the
244244
/// block B and some superregion of the call. If we forced it now, we'd choose the smaller
245245
/// region (the call). But that would make the *b illegal. Since we don't resolve, the type
246-
/// of b will be `&<R0>.isize` and then `*b` will require that `<R0>` be bigger than the let and
246+
/// of b will be `&<R0>.i32` and then `*b` will require that `<R0>` be bigger than the let and
247247
/// the `*b` expression, so we will effectively resolve `<R0>` to be the block B.
248248
pub fn resolve_type(&self, unresolved_ty: Ty<'tcx>) -> Ty<'tcx> {
249249
self.fcx.infcx().resolve_type_vars_if_possible(&unresolved_ty)

src/librustc_typeck/variance.rs

+7-7
Original file line numberDiff line numberDiff line change
@@ -172,14 +172,14 @@
172172
//!
173173
//! Now imagine that I have an implementation of `ConvertTo` for `Object`:
174174
//!
175-
//! impl ConvertTo<isize> for Object { ... }
175+
//! impl ConvertTo<i32> for Object { ... }
176176
//!
177177
//! And I want to call `convertAll` on an array of strings. Suppose
178178
//! further that for whatever reason I specifically supply the value of
179179
//! `String` for the type parameter `T`:
180180
//!
181181
//! let mut vector = vec!["string", ...];
182-
//! convertAll::<isize, String>(vector);
182+
//! convertAll::<i32, String>(vector);
183183
//!
184184
//! Is this legal? To put another way, can we apply the `impl` for
185185
//! `Object` to the type `String`? The answer is yes, but to see why
@@ -190,25 +190,25 @@
190190
//! - It will then call the impl of `convertTo()` that is intended
191191
//! for use with objects. This has the type:
192192
//!
193-
//! fn(self: &Object) -> isize
193+
//! fn(self: &Object) -> i32
194194
//!
195195
//! It is ok to provide a value for `self` of type `&String` because
196196
//! `&String <: &Object`.
197197
//!
198198
//! OK, so intuitively we want this to be legal, so let's bring this back
199199
//! to variance and see whether we are computing the correct result. We
200200
//! must first figure out how to phrase the question "is an impl for
201-
//! `Object,isize` usable where an impl for `String,isize` is expected?"
201+
//! `Object,i32` usable where an impl for `String,i32` is expected?"
202202
//!
203203
//! Maybe it's helpful to think of a dictionary-passing implementation of
204204
//! type classes. In that case, `convertAll()` takes an implicit parameter
205205
//! representing the impl. In short, we *have* an impl of type:
206206
//!
207-
//! V_O = ConvertTo<isize> for Object
207+
//! V_O = ConvertTo<i32> for Object
208208
//!
209209
//! and the function prototype expects an impl of type:
210210
//!
211-
//! V_S = ConvertTo<isize> for String
211+
//! V_S = ConvertTo<i32> for String
212212
//!
213213
//! As with any argument, this is legal if the type of the value given
214214
//! (`V_O`) is a subtype of the type expected (`V_S`). So is `V_O <: V_S`?
@@ -217,7 +217,7 @@
217217
//! covariant, it means that:
218218
//!
219219
//! V_O <: V_S iff
220-
//! isize <: isize
220+
//! i32 <: i32
221221
//! String <: Object
222222
//!
223223
//! These conditions are satisfied and so we are happy.

0 commit comments

Comments
 (0)