about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2023-07-26 15:27:36 +0000
committerbors <bors@rust-lang.org>2023-07-26 15:27:36 +0000
commit601a34de8c10458b72a7781eb0b44a7981e4a2b1 (patch)
tree0627d59eabaa4b0f7f6922b6b08bb6e497405f8f /compiler/rustc_codegen_llvm/src
parentbd9785cce8dffad58a793f85454a5064100e9c84 (diff)
parent24f90fdd2654e9c5437a684d3a72a4e70826a985 (diff)
downloadrust-601a34de8c10458b72a7781eb0b44a7981e4a2b1.tar.gz
rust-601a34de8c10458b72a7781eb0b44a7981e4a2b1.zip
Auto merge of #113457 - davidtwco:lint-ctypes-issue-113436, r=oli-obk
lint/ctypes: fix `()` return type checks

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](https://github.com/rust-lang/rust/issues/113436#issuecomment-1640756721), I've fixed the bugs and inconsistencies and  made `()` FFI-safe within types.

I also refactor a function, but that's not too exciting.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions