diff options
| author | bors <bors@rust-lang.org> | 2024-03-11 04:45:27 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-03-11 04:45:27 +0000 |
| commit | a6d93acf5fdeb020ab86cc0d30d5672c23a7dba6 (patch) | |
| tree | aa2473461cfbc2f595aed3c609d895c4add75624 /library/std/src/os/unix/io | |
| parent | c69fda7dc664e62f8920a02a4e55d6207b212c24 (diff) | |
| parent | f18c2f83e99ace7b9ad94a8204ff5fd68807ef34 (diff) | |
| download | rust-a6d93acf5fdeb020ab86cc0d30d5672c23a7dba6.tar.gz rust-a6d93acf5fdeb020ab86cc0d30d5672c23a7dba6.zip | |
Auto merge of #122050 - erikdesjardins:sret, r=nikic
Stop using LLVM struct types for byval/sret For `byval` and `sret`, the type has no semantic meaning, only the size matters\*†. Using `[N x i8]` is a more direct way to specify that we want `N` bytes, and avoids relying on LLVM's struct layout. \*: The alignment would matter, if we didn't explicitly specify it. From what I can tell, we always specified the alignment for `sret`; for `byval`, we didn't until #112157. †: For `byval`, the hidden copy may be impacted by padding in the LLVM struct type, i.e. padding bytes may not be copied. (I'm not sure if this is done today, but I think it would be legal.) But we manually pad our LLVM struct types specifically to avoid there ever being LLVM-visible padding, so that shouldn't be an issue. Split out from #121577. r? `@nikic`
Diffstat (limited to 'library/std/src/os/unix/io')
0 files changed, 0 insertions, 0 deletions