diff options
| author | bors <bors@rust-lang.org> | 2023-07-26 15:27:36 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-07-26 15:27:36 +0000 |
| commit | 601a34de8c10458b72a7781eb0b44a7981e4a2b1 (patch) | |
| tree | 0627d59eabaa4b0f7f6922b6b08bb6e497405f8f /compiler/rustc_codegen_llvm/src | |
| parent | bd9785cce8dffad58a793f85454a5064100e9c84 (diff) | |
| parent | 24f90fdd2654e9c5437a684d3a72a4e70826a985 (diff) | |
| download | rust-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
