@@ -44,7 +44,7 @@ pub fn rust_begin_panic(info: &PanicInfo<'_>) -> ! {
44
44
```
45
45
46
46
The special ` panic_handler ` attribute is resolved via ` src/librustc/middle/lang_items ` .
47
- The ` extract ` functions convers the ` panic_handler ` attribute to a ` panic_impl ` lang item.
47
+ The ` extract ` function converts the ` panic_handler ` attribute to a ` panic_impl ` lang item.
48
48
49
49
Now, we have a matching ` panic_impl ` lang item in the ` libstd ` . This function goes
50
50
through the same process as the ` extern { fn panic_impl } ` definition in ` libcore ` , ending
@@ -59,7 +59,7 @@ to go through the same infratructure that other panics use (panic hooks, unwindi
59
59
60
60
This is where the actual panic-related logic begins. In ` src/libstd/pancking.rs ` ,
61
61
control passes to ` rust_panic_with_hook ` . This method is responsible
62
- for checking for invoking the global panic hook, and checking for double panics. Finally,
62
+ for invoking the global panic hook, and checking for double panics. Finally,
63
63
we call ``` __rust_start_panic ``` , which is provided by the panic runtime.
64
64
65
65
The call to ``` __rust_start_panic ``` is very weird - it is passed a ``` *mut &mut dyn BoxMeUp ``` ,
@@ -101,5 +101,4 @@ with each frame (currently, running destructors), and transferring control
101
101
to the ` catch_unwind ` frame.
102
102
103
103
Note that all panics either abort the process or get caught by some call to ` catch_unwind ` :
104
- in ` src/libstd/rt.rs ` , the call to the user-provided ` main ` function is wrapped in `catch_unwind
105
-
104
+ in ` src/libstd/rt.rs ` , the call to the user-provided ` main ` function is wrapped in ` catch_unwind ` .
0 commit comments