I guess the Copy here is a red herring. Or at least it's surely not the only one responsible.
Sometimes, when you have a chain of errors leading to a bug, you can't clearly point to one of them and say "now that is the problem!".
I guess the nicest example of this phenomenon is shared mutability. Programmers have been arguing for decades whether it is sharing xor mutability that causes memory safety bugs:
- "It's threads!" – shouted JavaScript and Python, and JS remained single-threaded, and Python introduced the GIL.
- "It's mutability!" – screamed Haskell and Erlang, and they made (almost) everything immutable.
And then along came Rust, and said: "you are fools! You can have both sharing and mutability in the same language, as long as you isolate them from each other."
Similarly, I'd say a Copy enum is not a problem in itself. If it's a trivial enum, make it Copy. The root cause is calling a mutating method on a temporary, which is partially caused by the getter returning an owned value. (Returning owned values is not a problem in itself, either.)
If I write the equivalent code on the Playground, Clippy doesn't flag it, and I couldn't find a related lint. I'm not sure what the right solution here is, apart from simply not making a getter.