10000 discussion of nocapture · sarvex/rust-memory-model@d0b9eb3 · GitHub
[go: up one dir, main page]

Skip to content

Commit d0b9eb3

Browse files
committed
discussion of nocapture
1 parent 5219fac commit d0b9eb3

File tree

1 file changed

+42
-0
lines changed

1 file changed

+42
-0
lines changed

optimizations/nocapture_by_safe_fn.md

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
### Example
2+
3+
```rust
4+
fn escape_simple(x: &i32) -> usize {
5+
22
6+
}
7+
8+
fn escape_as_usize(x: &i32) -> usize {
9+
x as usize
10+
}
11+
12+
fn escape_as_ptr(x: &i32) -> *const i32 {
13+
x
14+
}
15+
16+
pub struct MyType(*const i32);
17+
18+
fn escape_as_newtype(x: &i32) -> MyType {
19+
MyType(x)
20+
}
21+
```
22+
23+
### Explanation
24+
25+
To be very LLVM specific, we'd like to add "nocapture" attributes.
26+
More generally, we'd like to be able to assume that if you have an
27+
argument of type `fn foo<'a>(x: &'a T) -> U`, and `'a` (nor any
28+
lifetime related to `'a`) does not appear in `U`, then we can assume
29+
that no alias of `x` escapes `foo`. However, it's not clear that we
30+
can always assume that.
31+
32+
- `escape_simple` -- no capture would be appropriate
33+
- `escape_as_newtype` -- same types as previous example, but in this case
34+
one might imagine that the user expects to coerce the result back to
35+
a pointer and use it. Is that legal?
36+
- `escape_as_ptr` -- same as above, but they were more explicit in their types.
37+
- `escape_as_newtype` -- same as above, but there is a newtype wrapping this
38+
`*const` -- maybe it forms a kind of abstraction boundary?
39+
40+
### Source
41+
42+
IRC conversation: https://botbot.me/mozilla/rustc/2016-02-24/?msg=60823650&page=1

0 commit comments

Comments
 (0)
0