You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It plays several different roles, depending on where it is used and whether the `unsafe_op_in_unsafe_fn` lint is enabled:
@@ -11,16 +14,25 @@ See the [keyword documentation][keyword] for some illustrative examples.
11
14
12
15
## Unsafe functions (`unsafe fn`)
13
16
17
+
r[unsafe.fn]
18
+
19
+
r[unsafe.fn.intro]
14
20
Unsafe functions are functions that are not safe in all contexts and/or for all possible inputs.
15
21
We say they have *extra safety conditions*, which are requirements that must be upheld by all callers and that the compiler does not check.
16
22
For example, [`get_unchecked`] has the extra safety condition that the index must be in-bounds.
17
23
The unsafe function should come with documentation explaining what those extra safety conditions are.
18
24
25
+
r[unsafe.fn.safety]
19
26
Such a function must be prefixed with the keyword `unsafe` and can only be called from inside an `unsafe` block, or inside `unsafe fn` without the [`unsafe_op_in_unsafe_fn`] lint.
20
27
21
28
## Unsafe blocks (`unsafe {}`)
22
29
30
+
r[unsafe.block]
31
+
32
+
r[unsafe.block.intro]
23
33
A block of code can be prefixed with the `unsafe` keyword, to permit calling `unsafe` functions or dereferencing raw pointers.
34
+
35
+
r[unsafe.block.fn-body]
24
36
By default, the body of an unsafe function is also considered to be an unsafe block;
25
37
this can be changed by enabling the [`unsafe_op_in_unsafe_fn`] lint.
26
38
@@ -41,13 +53,19 @@ By using `unsafe` blocks to represent the reverse links as raw pointers, it can
41
53
42
54
## Unsafe traits (`unsafe trait`)
43
55
56
+
r[unsafe.trait]
57
+
58
+
r[unsafe.trait.intro]
44
59
An unsafe trait is a trait that comes with extra safety conditions that must be upheld by *implementations* of the trait.
45
60
The unsafe trait should come with documentation explaining what those extra safety conditions are.
46
61
62
+
r[unsafe.trait.safety]
47
63
Such a trait must be prefixed with the keyword `unsafe` and can only be implemented by `unsafe impl` blocks.
48
64
49
65
## Unsafe trait implementations (`unsafe impl`)
50
66
67
+
r[unsafe.impl]
68
+
51
69
When implementing an unsafe trait, the implementation needs to be prefixed with the `unsafe` keyword.
52
70
By writing `unsafe impl`, the programmer states that they have taken care of satisfying the extra safety conditions required by the trait.
53
71
@@ -59,12 +77,16 @@ Unsafe trait implementations are the logical dual to unsafe traits: where unsafe
59
77
60
78
## Unsafe external blocks (`unsafe extern`)
61
79
80
+
r[unsafe.extern]
81
+
62
82
The programmer who declares an [external block] must assure that the signatures of the items contained within are correct. Failing to do so may lead to undefined behavior. That this obligation has been met is indicated by writing `unsafe extern`.
63
83
64
84
[external block]: items/external-blocks.md
65
85
66
86
## Unsafe attributes (`#[unsafe(attr)]`)
67
87
88
+
r[unsafe.attribute]
89
+
68
90
An [unsafe attribute] is one that has extra safety conditions that must be upheld when using the attribute. The compiler cannot check whether these conditions have been upheld. To assert that they have been, these attributes must be wrapped in `unsafe(..)`, e.g. `#[unsafe(no_mangle)]`.
0 commit comments