Repository navigation
Erroneous warning about packed struct not implementing Copy #71740
Copy link
Copy link
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)C-bugCategory: This is a bug.Category: This is a bug.E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
I tried this code:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7d186291bfe30222d01ed0af2fa28c4c
use serde::{Serialize, Deserialize};
#[repr(C)]
#[repr(packed)]
#[derive(Copy, Clone, Serialize, Deserialize, PartialEq, Debug)]
struct Packed {
a: u8,
b: u16,
c: u8
}
fn main() {}I expected to see this happen: Compile without any warning or error.
Instead, this happened: The following warning was emitted:
Compiling playground v0.0.1 (/playground)
warning: `#[derive]` can't be used on a `#[repr(packed)]` struct that does not derive Copy (error E0133)
--> src/main.rs:8:23
|
8 | #[derive(Copy, Clone, Serialize, Deserialize, PartialEq, Debug)]
| ^^^^^^^^^
|
= note: `#[warn(safe_packed_borrows)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #46043 <https://github.com/rust-lang/rust/issues/46043>
= note: this warning originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)
Finished dev [unoptimized + debuginfo] target(s) in 0.65s
Running `target/debug/playground`
Meta
rustc --version --verbose:
<version>
Backtrace
<backtrace>
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)C-bugCategory: This is a bug.Category: This is a bug.E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable ExampleT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
RalfJung commentedon May 1, 2020
Hm, the error is certainly not good.
I suspect
derive(Serialize)still creates unaligned references to packed fields internally even if the type isCopy. In other words, the macro just currently cannot support packed structs -- that would have to be fixed on the serde side, if it is possible at all.Fixing the error is a rustc bug, though.
RalfJung commentedon May 1, 2020
I think each derive needs to be adjusted to handle this... but I don't actually know and did not look at the code.
Yeah, this shows that serde does not properly make a copy.
RalfJung commentedon May 10, 2020
Agreed, the rustc diagnostic should be improved. What it says is correct for the built-in
derivebut does not make sense for user-definedderive.estebank commentedon Oct 21, 2023
The original code now compiles, but we need a repro to evaluate the diagnostic.
RalfJung commentedon Oct 21, 2023
@nnethercote did a bunch of
derivework recently, not sure if it would have fixed this.nnethercote commentedon Oct 23, 2023
I did make changes to packed structs in #104429 but I don't think that will affect this example, which has
derive(Copy).The original error no longer occurs because of the serde fix. One way to get a reproducing test case would be to undo that change in serde. Or it might be reasonable just to close this issue given that the error message is no longer occurring in practice.
nnethercote commentedon Oct 23, 2023
Actually, looks like #104429 did remove that error. So I think this can be closed.