-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experimentally add ffi_const
and ffi_pure
extern fn attributes
#58327
Changes from all commits
d8344ff
bf149c0
945cbe4
736c437
3adeddd
effaf14
26eb8b0
c11a27f
d663711
a3d0f3c
3770725
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,51 @@ | ||
# `c_ffi_const` | ||
|
||
The `#[c_ffi_const]` attribute applies clang's `const` attribute to foreign | ||
functions declarations. | ||
|
||
That is, `#[c_ffi_const]` functions shall have no effects except for its return | ||
value, which can only depend on the values of the function parameters, and is | ||
not affected by changes to the observable state of the program. | ||
|
||
The behavior of calling a `#[c_ffi_const]` function that violates these | ||
requirements is undefined. | ||
|
||
This attribute enables Rust to perform common optimizations, like sub-expression | ||
elimination, and it can avoid emitting some calls in repeated invocations of the | ||
function with the same argument values regardless of other operations being | ||
performed in between these functions calls (as opposed to `#[c_ffi_pure]` | ||
functions). | ||
|
||
## Pitfalls | ||
|
||
A `#[c_ffi_const]` function can only read global memory that would not affect | ||
its return value for the whole execution of the program (e.g. immutable global | ||
memory). `#[c_ffi_const]` functions are referentially-transparent and therefore | ||
more strict than `#[c_ffi_pure]` functions. | ||
|
||
A common pitfall involves applying the `#[c_ffi_const]` attribute to a | ||
function that reads memory through pointer arguments which do not necessarily | ||
point to immutable global memory. | ||
|
||
A `#[c_ffi_const]` function that returns unit has no effect on the abstract | ||
machine's state, and a `#[c_ffi_const]` function cannot be `#[c_ffi_pure]`. | ||
|
||
A diverging and C or C++ `const` function is unreachable. Diverging via a | ||
side-effect (e.g. a call to `abort`) violates `const` pre-conditions. Divergence | ||
without side-effects is undefined behavior in C++ and not possible in C. In C++, | ||
the behavior of infinite loops without side-effects is undefined, while in C | ||
these loops can be assumed to terminate. This would cause a diverging function | ||
to return, invoking undefined behavior. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This paragraph confuses me, I think it might incidentally mislead users too, and I don't even think it is technically correct
I think we should just say as a separate axiom that functions marked with this attribute must not diverge. GCC's docs don't say this as far as I can see (at least explicitly -- arguably non-termination is an observable effect), but it's kind of the safer assumption because who knows what LLVM's implicit assumptions around |
||
|
||
When translating C headers to Rust FFI, it is worth verifying for which targets | ||
the `const` attribute is enabled in those headers, and using the appropriate | ||
`cfg` macros in the Rust side to match those definitions. While the semantics of | ||
`const` are implemented identically by many C and C++ compilers, e.g., clang, | ||
[GCC], [ARM C/C++ compiler], [IBM ILE C/C++], etc. they are not necessarily | ||
implemented in this way on all of them. It is therefore also worth verifying | ||
that the semantics of the C toolchain used to compile the binary being linked | ||
against are compatible with those of the `#[c_ffi_const]`. | ||
|
||
[ARM C/C++ compiler]: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/Cacgigch.html | ||
[GCC]: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-const-function-attribute | ||
[IBM ILE C/C++]: https://www.ibm.com/support/knowledgecenter/fr/ssw_ibm_i_71/rzarg/fn_attrib_const.htm |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
# `c_ffi_pure` | ||
|
||
The `#[c_ffi_pure]` attribute applies clang's `pure` attribute to foreign | ||
functions declarations. | ||
|
||
That is, `#[c_ffi_pure]` functions shall have no effects except for its return | ||
value, which shall not change across two consecutive function calls and can only | ||
depend on the values of the function parameters and/or global memory. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This doesn't sound right. GCC docs specifically state pure functions can read arbitrary non-volatile memory. I don't know for sure what you mean by "global memory" is but certainly pure functions can be passed pointers to a caller's local variables and read them through those pointers. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it can do all that and even more. And I don't think this paragraph properly conveys that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you have any suggestion? Being able to read caller local variables via pointers passed to them is AFAICT already covered by "depend on the values of the function parameters", and by global memory I mean any memory that is globally accessible, e.g., via an static, a magic address, etc. (not necessarily something that's passed to the function as a parameter). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (Sorry for the delay.) I think language like in the GCC docs (arbitrary memory) is better. The phrase "values of the function parameters" is not clear for pointer arguments because it can be read as "only depend on the pointer itself, not the contents of the memory it points to" and indeed that's sort of the case for |
||
|
||
The behavior of calling a `#[c_ffi_pure]` function that violates these | ||
requirements is undefined. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As for const: it should be UB to have a declaration wrongly annotated |
||
|
||
This attribute enables Rust to perform common optimizations, like sub-expression | ||
elimination and loop optimizations. Some common examples of pure functions are | ||
`strlen` or `memcmp`. | ||
|
||
These optimizations only apply across successive invocations of the function, | ||
since any other function could modify global memory read by `#[c_ffi_pure]` | ||
functions, altering their result. The `#[c_ffi_const]` attribute allows | ||
sub-expression elimination regardless of any operations in between the function | ||
calls. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I see what you're getting at here but this wording is misleading. It is harder for the optimizer to apply CSE because it has to show that no relevant state changed between two calls it wants to CSE, but "only apply across successive invocations" only communicates that if it means "directly adjacent without anything/much in between", which is too strong as stated (e.g., it might be known that the pure function doesn't read certain memory, or that another function called in between doesn't write memory). I think I'd prefer to weaken this note to just briefly describe the difficulties imposed on the optimizer by the weaker rules of pure vs const and not get into the hairy business of predicting what that actually means for when the optimization fires or not. |
||
|
||
## Pitfalls | ||
|
||
A `#[c_ffi_pure]` function can read global memory through the function | ||
parameters (e.g. pointers), globals, etc. `#[c_ffi_pure]` functions are not | ||
referentially-transparent, and are therefore more relaxed than `#[c_ffi_const]` | ||
functions. | ||
|
||
However, accesing global memory through volatile or atomic reads can violate the | ||
requirement that two consecutive function calls shall return the same value. | ||
|
||
A `pure` function that returns unit has no effect on the abstract machine's | ||
state. | ||
|
||
A diverging and `pure` C or C++ function is unreachable. Diverging via a | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same point about termination as with |
||
side-effect (e.g. a call to `abort`) violates `pure` requirements. Divergence | ||
without side-effects is undefined behavior in C++ and not possible in C. In C++, | ||
the behavior of infinite loops without side-effects is undefined, while in C | ||
these loops can be assumed to terminate. This would cause a diverging function | ||
to return, invoking undefined behavior. | ||
|
||
When translating C headers to Rust FFI, it is worth verifying for which targets | ||
the `pure` attribute is enabled in those headers, and using the appropriate | ||
`cfg` macros in the Rust side to match those definitions. While the semantics of | ||
`pure` are implemented identically by many C and C++ compilers, e.g., clang, | ||
[GCC], [ARM C/C++ compiler], [IBM ILE C/C++], etc. they are not necessarily | ||
implemented in this way on all of them. It is therefore also worth verifying | ||
that the semantics of the C toolchain used to compile the binary being linked | ||
against are compatible with those of the `#[c_ffi_pure]`. | ||
|
||
|
||
[ARM C/C++ compiler]: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/Cacigdac.html | ||
[GCC]: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-pure-function-attribute | ||
[IBM ILE C/C++]: https://www.ibm.com/support/knowledgecenter/fr/ssw_ibm_i_71/rzarg/fn_attrib_pure.htm |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
// compile-flags: -C no-prepopulate-passes | ||
#![crate_type = "lib"] | ||
#![feature(c_ffi_const)] | ||
|
||
pub fn bar() { unsafe { foo() } } | ||
|
||
extern { | ||
// CHECK-LABEL: declare void @foo() | ||
// CHECK-SAME: [[ATTRS:#[0-9]+]] | ||
// CHECK-DAG: attributes [[ATTRS]] = { {{.*}}readnone{{.*}} } | ||
#[c_ffi_const] pub fn foo(); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
// compile-flags: -C no-prepopulate-passes | ||
#![crate_type = "lib"] | ||
#![feature(c_ffi_pure)] | ||
|
||
pub fn bar() { unsafe { foo() } } | ||
|
||
extern { | ||
// CHECK-LABEL: declare void @foo() | ||
// CHECK-SAME: [[ATTRS:#[0-9]+]] | ||
// CHECK-DAG: attributes [[ATTRS]] = { {{.*}}readonly{{.*}} } | ||
#[c_ffi_pure] pub fn foo(); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
// ignore-tidy-linelength | ||
#![feature(c_ffi_const, c_ffi_pure)] | ||
#![crate_type = "lib"] | ||
|
||
#[c_ffi_const] //~ ERROR `#[c_ffi_const]` may only be used on foreign functions [E0725] | ||
pub fn foo() {} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
error[E0725]: `#[c_ffi_const]` may only be used on foreign functions | ||
--> $DIR/c_ffi_const.rs:5:1 | ||
| | ||
LL | #[c_ffi_const] //~ ERROR `#[c_ffi_const]` may only be used on foreign functions [E0725] | ||
| ^^^^^^^^^^^^^^ | ||
|
||
error: aborting due to previous error | ||
|
||
For more information about this error, try `rustc --explain E0725`. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
// ignore-tidy-linelength | ||
#![feature(c_ffi_const, c_ffi_pure)] | ||
|
||
extern { | ||
#[c_ffi_pure] //~ ERROR `#[c_ffi_const]` function cannot be`#[c_ffi_pure]` [E0726] | ||
#[c_ffi_const] | ||
pub fn baz(); | ||
} | ||
|
||
fn main() { | ||
unsafe { baz() }; | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
error[E0726]: `#[c_ffi_const]` function cannot be`#[c_ffi_pure]` | ||
--> $DIR/c_ffi_const2.rs:5:5 | ||
| | ||
LL | #[c_ffi_pure] //~ ERROR `#[c_ffi_const]` function cannot be`#[c_ffi_pure]` [E0726] | ||
| ^^^^^^^^^^^^^ | ||
|
||
error: aborting due to previous error | ||
|
||
For more information about this error, try `rustc --explain E0726`. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
// ignore-tidy-linelength | ||
#![feature(c_ffi_pure)] | ||
#![crate_type = "lib"] | ||
|
||
#[c_ffi_pure] //~ ERROR `#[c_ffi_pure]` may only be used on foreign functions [E0724] | ||
pub fn foo() {} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
error[E0724]: `#[c_ffi_pure]` may only be used on foreign functions | ||
--> $DIR/c_ffi_pure.rs:5:1 | ||
| | ||
LL | #[c_ffi_pure] //~ ERROR `#[c_ffi_pure]` may only be used on foreign functions [E0724] | ||
| ^^^^^^^^^^^^^ | ||
|
||
error: aborting due to previous error | ||
|
||
For more information about this error, try `rustc --explain E0724`. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
// ignore-tidy-linelength | ||
#![crate_type = "lib"] | ||
|
||
extern { | ||
#[c_ffi_const] //~ ERROR the `#[c_ffi_const]` attribute is an experimental feature (see issue #58328) | ||
pub fn foo(); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
error[E0658]: the `#[c_ffi_const]` attribute is an experimental feature (see issue #58328) | ||
--> $DIR/feature-gate-c_ffi_const.rs:5:5 | ||
| | ||
LL | #[c_ffi_const] //~ ERROR the `#[c_ffi_const]` attribute is an experimental feature (see issue #58328) | ||
| ^^^^^^^^^^^^^^ | ||
| | ||
= help: add #![feature(c_ffi_const)] to the crate attributes to enable | ||
|
||
error: aborting due to previous error | ||
|
||
For more information about this error, try `rustc --explain E0658`. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
// ignore-tidy-linelength | ||
#![crate_type = "lib"] | ||
|
||
extern { | ||
#[c_ffi_pure] //~ ERROR the `#[c_ffi_pure]` attribute is an experimental feature (see issue #58329) | ||
pub fn foo(); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
error[E0658]: the `#[c_ffi_pure]` attribute is an experimental feature (see issue #58329) | ||
--> $DIR/feature-gate-c_ffi_pure.rs:5:5 | ||
| | ||
LL | #[c_ffi_pure] //~ ERROR the `#[c_ffi_pure]` attribute is an experimental feature (see issue #58329) | ||
| ^^^^^^^^^^^^^ | ||
| | ||
= help: add #![feature(c_ffi_pure)] to the crate attributes to enable | ||
|
||
error: aborting due to previous error | ||
|
||
For more information about this error, try `rustc --explain E0658`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be UB to even have a wrongly annotated declaration, saying it's UB if the function is called doesn't justify speculatively executing it (e.g., hoisting out of branches) .