-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
lint/ctypes: fix ()
return type checks
#113457
Conversation
r? @oli-obk (rustbot has picked a reviewer for you, use r? to override) |
Probably needs a crater run, quite confident this is correct, but it doubles down on a regression. |
@bors try |
⌛ Trying commit 550c0126541435f5837c0778f1899349c322943c with merge b67f81b43b417bb7d00053f011fd9a7d6817a6bc... |
Why is this considered FFI-safe: #[repr(C)]
pub struct Foo {
a: u8,
b: core::marker::PhantomData<()>,
} ... but this is not: #[repr(C)]
pub struct Foo {
a: u8,
b: (),
} Aren't they both guaranteed to have the same layout and ABI as this C struct? struct Foo {
uint8_t a;
}; |
☀️ Try build successful - checks-actions |
See #113436 (comment) for some thoughts on this - this patch will change the behaviour to fix this, if that's what we decide we want. |
I've asked for some feedback on Zulip about which direction to go here. |
`()` is normally FFI-unsafe, but is FFI-safe when used as a return type. It is also desirable that a transparent newtype for `()` is FFI-safe when used as a return type. In order to support this, when an type was deemed FFI-unsafe, because of a `()` type, and was used in return type - then the type was considered FFI-safe. However, this was the wrong approach - it didn't check that the `()` was part of a transparent newtype! The consequence of this is that the presence of a `()` type in a more complex return type would make it the entire type be considered safe (as long as the `()` type was the first that the lint found) - which is obviously incorrect. Instead, this logic is removed, and a unit return type or a transparent wrapper around a unit is checked for directly for functions and fn-ptrs. Signed-off-by: David Wood <[email protected]>
Simplify this function a bit, it was quite hard to reason about. Signed-off-by: David Wood <[email protected]>
Consider `()` within types to be FFI-safe, and `()` to be FFI-safe as a return type (incl. when in a transparent newtype). Signed-off-by: David Wood <[email protected]>
()
return type checks()
return type checks
550c012
to
24f90fd
Compare
This should now be ready for review. |
@bors try |
⌛ Trying commit 24f90fd with merge e58ab0492e70733577a2aa8f09aa11a81ccf8005... |
☀️ Try build successful - checks-actions |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
All of these seem unrelated to the changes in this PR, I think the crater run is okay :) |
@bors r+ |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
Finished benchmarking commit (601a34d): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 650.721s -> 650.146s (-0.09%) |
[beta] backport * Restrict linker version script of proc-macro crates to just its two symbols rust-lang#114470 * bootstrap: config: fix version comparison bug rust-lang#114440 * lint/ctypes: only try normalize rust-lang#113921 * Avoid tls access while iterating through mpsc thread entries rust-lang#113861 * Substitute types before checking inlining compatibility. rust-lang#113802 * Revert "fix: bug etc/bash_complettion -> src/etc/... to avoid copy error" rust-lang#113579 * lint/ctypes: fix () return type checks rust-lang#113457 * Rename and allow cast_ref_to_mut lint rust-lang#113422 * Ignore flaky clippy tests. rust-lang#113621 r? cuviper
Fixes #113436.
()
is normally FFI-unsafe, but is FFI-safe when used as a return type. It is also desirable that a transparent newtype for()
is FFI-safe when used as a return type.In order to support this, when a type was deemed FFI-unsafe, because of a
()
type, and was used in return type - then the type was considered FFI-safe. However, this was the wrong approach - it didn't check that the()
was part of a transparent newtype! The consequence of this is that the presence of a()
type in a more complex return type would make it the entire type be considered safe (as long as the()
type was the first that the lint found) - which is obviously incorrect.Instead, this logic is removed, and after consultation with t-lang, I've fixed the bugs and inconsistencies and made
()
FFI-safe within types.I also refactor a function, but that's not too exciting.