Skip to content

Commit eebcc8f

Browse files
mike-marcaccimike-marcacci
committed
---
yaml --- r: 233185 b: refs/heads/beta c: bcf3921 h: refs/heads/master i: 233183: 9df7665 v: v3
1 parent d6b8966 commit eebcc8f

File tree

5 files changed

+137
-140
lines changed

5 files changed

+137
-140
lines changed

‎[refs]

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,7 @@ refs/tags/0.9: 36870b185fc5f5486636d4515f0e22677493f225
2323
refs/tags/0.10: ac33f2b15782272ae348dbd7b14b8257b2148b5a
2424
refs/tags/0.11.0: e1247cb1d0d681be034adb4b558b5a0c0d5720f9
2525
refs/tags/0.12.0: f0c419429ef30723ceaf6b42f9b5a2aeb5d2e2d1
26-
refs/heads/beta: 920cf4b4b2cc9a061b14c49c8dcd0af4e4e19845
26+
refs/heads/beta: bcf3921a2aaf72c0f7a3e052dd2ef20f188054a3
2727
refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
2828
refs/heads/tmp: 370fe2786109360f7c35b8ba552b83b773dd71d6
2929
refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f

‎branches/beta/src/doc/trpl/the-stack-and-the-heap.md

Lines changed: 133 additions & 133 deletions
Original file line numberDiff line numberDiff line change
@@ -217,12 +217,12 @@ on the heap. The actual value of the box is a structure which has a pointer to
217217
it allocates some memory for the heap, and puts `5` there. The memory now looks
218218
like this:
219219

220-
| Address | Name | Value |
221-
|-----------------|------|----------------|
222-
| 2<sup>30</sup> | | 5 |
223-
| ... | ... | ... |
224-
| 1 | y | 42 |
225-
| 0 | x | 2<sup>30</sup> |
220+
| Address | Name | Value |
221+
|-----------------|------|------------------|
222+
| 2<sup>30</sup> | | 5 |
223+
| ... | ... | ... |
224+
| 1 | y | 42 |
225+
| 0 | x | → 2<sup>30</sup> |
226226

227227
We have 2<sup>30</sup> in our hypothetical computer with 1GB of RAM. And since
228228
our stack grows from zero, the easiest place to allocate memory is from the
@@ -242,17 +242,17 @@ freed in any order, it can end up with ‘holes’. Here’s a diagram of the me
242242
layout of a program which has been running for a while now:
243243

244244

245-
| Address | Name | Value |
246-
|----------------------|------|----------------------|
247-
| 2<sup>30</sup> | | 5 |
248-
| (2<sup>30</sup>) - 1 | | |
249-
| (2<sup>30</sup>) - 2 | | |
250-
| (2<sup>30</sup>) - 3 | | 42 |
251-
| ... | ... | ... |
252-
| 3 | y | (2<sup>30</sup>) - 3 |
253-
| 2 | y | 42 |
254-
| 1 | y | 42 |
255-
| 0 | x | 2<sup>30</sup> |
245+
| Address | Name | Value |
246+
|----------------------|------|------------------------|
247+
| 2<sup>30</sup> | | 5 |
248+
| (2<sup>30</sup>) - 1 | | |
249+
| (2<sup>30</sup>) - 2 | | |
250+
| (2<sup>30</sup>) - 3 | | 42 |
251+
| ... | ... | ... |
252+
| 3 | y | → (2<sup>30</sup>) - 3 |
253+
| 2 | y | 42 |
254+
| 1 | y | 42 |
255+
| 0 | x | → 2<sup>30</sup> |
256256

257257
In this case, we’ve allocated four things on the heap, but deallocated two of
258258
them. There’s a gap between 2<sup>30</sup> and (2<sup>30</sup>) - 3 which isn’t
@@ -304,22 +304,22 @@ fn main() {
304304

305305
When we enter `main()`, memory looks like this:
306306

307-
| Address | Name | Value |
308-
|---------|------|-------|
309-
| 1 | y | 0 |
310-
| 0 | x | 5 |
307+
| Address | Name | Value |
308+
|---------|------|--------|
309+
| 1 | y | → 0 |
310+
| 0 | x | 5 |
311311

312312
`x` is a plain old `5`, and `y` is a reference to `x`. So its value is the
313313
memory location that `x` lives at, which in this case is `0`.
314314

315315
What about when we call `foo()`, passing `y` as an argument?
316316

317-
| Address | Name | Value |
318-
|---------|------|-------|
319-
| 3 | z | 42 |
320-
| 2 | i | 0 |
321-
| 1 | y | 0 |
322-
| 0 | x | 5 |
317+
| Address | Name | Value |
318+
|---------|------|--------|
319+
| 3 | z | 42 |
320+
| 2 | i | → 0 |
321+
| 1 | y | → 0 |
322+
| 0 | x | 5 |
323323

324324
Stack frames aren’t just for local bindings, they’re for arguments too. So in
325325
this case, we need to have both `i`, our argument, and `z`, our local variable
@@ -366,152 +366,152 @@ fn main() {
366366

367367
First, we call `main()`:
368368

369-
| Address | Name | Value |
370-
|-----------------|------|----------------|
371-
| 2<sup>30</sup> | | 20 |
372-
| ... | ... | ... |
373-
| 2 | j | 0 |
374-
| 1 | i | 2<sup>30</sup> |
375-
| 0 | h | 3 |
369+
| Address | Name | Value |
370+
|-----------------|------|------------------|
371+
| 2<sup>30</sup> | | 20 |
372+
| ... | ... | ... |
373+
| 2 | j | → 0 |
374+
| 1 | i | → 2<sup>30</sup> |
375+
| 0 | h | 3 |
376376

377377
We allocate memory for `j`, `i`, and `h`. `i` is on the heap, and so has a
378378
value pointing there.
379379

380380
Next, at the end of `main()`, `foo()` gets called:
381381

382-
| Address | Name | Value |
383-
|-----------------|------|----------------|
384-
| 2<sup>30</sup> | | 20 |
385-
| ... | ... | ... |
386-
| 5 | z | 4 |
387-
| 4 | y | 10 |
388-
| 3 | x | 0 |
389-
| 2 | j | 0 |
390-
| 1 | i | 2<sup>30</sup> |
391-
| 0 | h | 3 |
382+
| Address | Name | Value |
383+
|-----------------|------|-----------------|
384+
| 2<sup>30</sup> | | 20 |
385+
| ... | ... | ... |
386+
| 5 | z | → 4 |
387+
| 4 | y | 10 |
388+
| 3 | x | → 0 |
389+
| 2 | j | → 0 |
390+
| 1 | i | → 2<sup>30</sup>|
391+
| 0 | h | 3 |
392392

393393
Space gets allocated for `x`, `y`, and `z`. The argument `x` has the same value
394394
as `j`, since that’s what we passed it in. It’s a pointer to the `0` address,
395395
since `j` points at `h`.
396396

397397
Next, `foo()` calls `baz()`, passing `z`:
398398

399-
| Address | Name | Value |
400-
|-----------------|------|----------------|
401-
| 2<sup>30</sup> | | 20 |
402-
| ... | ... | ... |
403-
| 7 | g | 100 |
404-
| 6 | f | 4 |
405-
| 5 | z | 4 |
406-
| 4 | y | 10 |
407-
| 3 | x | 0 |
408-
| 2 | j | 0 |
409-
| 1 | i | 2<sup>30</sup> |
410-
| 0 | h | 3 |
399+
| Address | Name | Value |
400+
|-----------------|------|------------------|
401+
| 2<sup>30</sup> | | 20 |
402+
| ... | ... | ... |
403+
| 7 | g | 100 |
404+
| 6 | f | → 4 |
405+
| 5 | z | → 4 |
406+
| 4 | y | 10 |
407+
| 3 | x | → 0 |
408+
| 2 | j | → 0 |
409+
| 1 | i | → 2<sup>30</sup> |
410+
| 0 | h | 3 |
411411

412412
We’ve allocated memory for `f` and `g`. `baz()` is very short, so when it’s
413413
over, we get rid of its stack frame:
414414

415-
| Address | Name | Value |
416-
|-----------------|------|----------------|
417-
| 2<sup>30</sup> | | 20 |
418-
| ... | ... | ... |
419-
| 5 | z | 4 |
420-
| 4 | y | 10 |
421-
| 3 | x | 0 |
422-
| 2 | j | 0 |
423-
| 1 | i | 2<sup>30</sup> |
424-
| 0 | h | 3 |
415+
| Address | Name | Value |
416+
|-----------------|------|------------------|
417+
| 2<sup>30</sup> | | 20 |
418+
| ... | ... | ... |
419+
| 5 | z | → 4 |
420+
| 4 | y | 10 |
421+
| 3 | x | → 0 |
422+
| 2 | j | → 0 |
423+
| 1 | i | → 2<sup>30</sup> |
424+
| 0 | h | 3 |
425425

426426
Next, `foo()` calls `bar()` with `x` and `z`:
427427

428-
| Address | Name | Value |
429-
|----------------------|------|----------------------|
430-
| 2<sup>30</sup> | | 20 |
431-
| (2<sup>30</sup>) - 1 | | 5 |
432-
| ... | ... | ... |
433-
| 10 | e | 9 |
434-
| 9 | d | (2<sup>30</sup>) - 1 |
435-
| 8 | c | 5 |
436-
| 7 | b | 4 |
437-
| 6 | a | 0 |
438-
| 5 | z | 4 |
439-
| 4 | y | 10 |
440-
| 3 | x | 0 |
441-
| 2 | j | 0 |
442-
| 1 | i | 2<sup>30</sup> |
443-
| 0 | h | 3 |
428+
| Address | Name | Value |
429+
|----------------------|------|------------------------|
430+
| 2<sup>30</sup> | | 20 |
431+
| (2<sup>30</sup>) - 1 | | 5 |
432+
| ... | ... | ... |
433+
| 10 | e | → 9 |
434+
| 9 | d | → (2<sup>30</sup>) - 1 |
435+
| 8 | c | 5 |
436+
| 7 | b | → 4 |
437+
| 6 | a | → 0 |
438+
| 5 | z | → 4 |
439+
| 4 | y | 10 |
440+
| 3 | x | → 0 |
441+
| 2 | j | → 0 |
442+
| 1 | i | → 2<sup>30</sup> |
443+
| 0 | h | 3 |
444444

445445
We end up allocating another value on the heap, and so we have to subtract one
446446
from 2<sup>30</sup>. It’s easier to just write that than `1,073,741,823`. In any
447447
case, we set up the variables as usual.
448448

449449
At the end of `bar()`, it calls `baz()`:
450450

451-
| Address | Name | Value |
452-
|----------------------|------|----------------------|
453-
| 2<sup>30</sup> | | 20 |
454-
| (2<sup>30</sup>) - 1 | | 5 |
455-
| ... | ... | ... |
456-
| 12 | g | 100 |
457-
| 11 | f | 9 |
458-
| 10 | e | 9 |
459-
| 9 | d | (2<sup>30</sup>) - 1 |
460-
| 8 | c | 5 |
461-
| 7 | b | 4 |
462-
| 6 | a | 0 |
463-
| 5 | z | 4 |
464-
| 4 | y | 10 |
465-
| 3 | x | 0 |
466-
| 2 | j | 0 |
467-
| 1 | i | 2<sup>30</sup> |
468-
| 0 | h | 3 |
451+
| Address | Name | Value |
452+
|----------------------|------|------------------------|
453+
| 2<sup>30</sup> | | 20 |
454+
| (2<sup>30</sup>) - 1 | | 5 |
455+
| ... | ... | ... |
456+
| 12 | g | 100 |
457+
| 11 | f | → 9 |
458+
| 10 | e | → 9 |
459+
| 9 | d | → (2<sup>30</sup>) - 1 |
460+
| 8 | c | 5 |
461+
| 7 | b | → 4 |
462+
| 6 | a | → 0 |
463+
| 5 | z | → 4 |
464+
| 4 | y | 10 |
465+
| 3 | x | → 0 |
466+
| 2 | j | → 0 |
467+
| 1 | i | → 2<sup>30</sup> |
468+
| 0 | h | 3 |
469469

470470
With this, we’re at our deepest point! Whew! Congrats for following along this
471471
far.
472472

473473
After `baz()` is over, we get rid of `f` and `g`:
474474

475-
| Address | Name | Value |
476-
|----------------------|------|----------------------|
477-
| 2<sup>30</sup> | | 20 |
478-
| (2<sup>30</sup>) - 1 | | 5 |
479-
| ... | ... | ... |
480-
| 10 | e | 9 |
481-
| 9 | d | (2<sup>30</sup>) - 1 |
482-
| 8 | c | 5 |
483-
| 7 | b | 4 |
484-
| 6 | a | 0 |
485-
| 5 | z | 4 |
486-
| 4 | y | 10 |
487-
| 3 | x | 0 |
488-
| 2 | j | 0 |
489-
| 1 | i | 2<sup>30</sup> |
490-
| 0 | h | 3 |
475+
| Address | Name | Value |
476+
|----------------------|------|------------------------|
477+
| 2<sup>30</sup> | | 20 |
478+
| (2<sup>30</sup>) - 1 | | 5 |
479+
| ... | ... | ... |
480+
| 10 | e | → 9 |
481+
| 9 | d | → (2<sup>30</sup>) - 1 |
482+
| 8 | c | 5 |
483+
| 7 | b | → 4 |
484+
| 6 | a | → 0 |
485+
| 5 | z | → 4 |
486+
| 4 | y | 10 |
487+
| 3 | x | → 0 |
488+
| 2 | j | → 0 |
489+
| 1 | i | → 2<sup>30</sup> |
490+
| 0 | h | 3 |
491491

492492
Next, we return from `bar()`. `d` in this case is a `Box<T>`, so it also frees
493493
what it points to: (2<sup>30</sup>) - 1.
494494

495-
| Address | Name | Value |
496-
|-----------------|------|----------------|
497-
| 2<sup>30</sup> | | 20 |
498-
| ... | ... | ... |
499-
| 5 | z | 4 |
500-
| 4 | y | 10 |
501-
| 3 | x | 0 |
502-
| 2 | j | 0 |
503-
| 1 | i | 2<sup>30</sup> |
504-
| 0 | h | 3 |
495+
| Address | Name | Value |
496+
|-----------------|------|------------------|
497+
| 2<sup>30</sup> | | 20 |
498+
| ... | ... | ... |
499+
| 5 | z | → 4 |
500+
| 4 | y | 10 |
501+
| 3 | x | → 0 |
502+
| 2 | j | → 0 |
503+
| 1 | i | → 2<sup>30</sup> |
504+
| 0 | h | 3 |
505505

506506
And after that, `foo()` returns:
507507

508-
| Address | Name | Value |
509-
|-----------------|------|----------------|
510-
| 2<sup>30</sup> | | 20 |
511-
| ... | ... | ... |
512-
| 2 | j | 0 |
513-
| 1 | i | 2<sup>30</sup> |
514-
| 0 | h | 3 |
508+
| Address | Name | Value |
509+
|-----------------|------|------------------|
510+
| 2<sup>30</sup> | | 20 |
511+
| ... | ... | ... |
512+
| 2 | j | → 0 |
513+
| 1 | i | → 2<sup>30</sup> |
514+
| 0 | h | 3 |
515515

516516
And then, finally, `main()`, which cleans the rest up. When `i` is `Drop`ped,
517517
it will clean up the last of the heap too.

‎branches/beta/src/librustc_typeck/check/cast.rs

Lines changed: 1 addition & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -100,7 +100,6 @@ enum CastError {
100100
DifferingKinds,
101101
IllegalCast,
102102
NeedViaPtr,
103-
NeedViaThinPtr,
104103
NeedViaInt,
105104
NeedViaUsize,
106105
NonScalar,
@@ -121,7 +120,6 @@ impl<'tcx> CastCheck<'tcx> {
121120
e: CastError) {
122121
match e {
123122
CastError::NeedViaPtr |
124-
CastError::NeedViaThinPtr |
125123
CastError::NeedViaInt |
126124
CastError::NeedViaUsize => {
127125
fcx.type_error_message(self.span, |actual| {
@@ -132,7 +130,6 @@ impl<'tcx> CastCheck<'tcx> {
132130
fcx.ccx.tcx.sess.fileline_help(self.span,
133131
&format!("cast through {} first", match e {
134132
CastError::NeedViaPtr => "a raw pointer",
135-
CastError::NeedViaThinPtr => "a thin pointer",
136133
CastError::NeedViaInt => "an integer",
137134
CastError::NeedViaUsize => "a usize",
138135
_ => unreachable!()
@@ -327,7 +324,7 @@ impl<'tcx> CastCheck<'tcx> {
327324
if fcx.type_is_known_to_be_sized(m_expr.ty, self.span) {
328325
Ok(CastKind::PtrAddrCast)
329326
} else {
330-
Err(CastError::NeedViaThinPtr)
327+
Err(CastError::NeedViaPtr)
331328
}
332329
}
333330

‎branches/beta/src/test/compile-fail/cast-rfc0401.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -96,7 +96,7 @@ fn main()
9696
let _ = &f as *const f64; //~ ERROR casting
9797
let _ = fat_v as usize;
9898
//~^ ERROR casting
99-
//~^^ HELP through a thin pointer first
99+
//~^^ HELP through a raw pointer first
100100

101101
let a : *const str = "hello";
102102
let _ = a as *const Foo;

‎branches/beta/src/test/compile-fail/fat-ptr-cast.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ fn main() {
2121
b as usize; //~ ERROR non-scalar cast
2222
p as usize;
2323
//~^ ERROR casting
24-
//~^^ HELP cast through a thin pointer
24+
//~^^ HELP cast through a raw pointer
2525

2626
// #22955
2727
q as *const [i32]; //~ ERROR casting

0 commit comments

Comments
 (0)