Fix contractimport for custom discriminants (#834)

[Smephite]

What

Add the Copy trait to derived custom types when using contractimport

Why

Close #834.

Known limitations

This should not expose any issues as Integer Variant Enums as described in the docs should derive Clone anyhow.

[leighmcculloch]

It looks like this PR adds Copy to all types of contract types, however I think we need to limit it to contracttype on integer enums, and contracterror types.

[kalepail]

What's the recommended work around here? It just seems very odd/unintuitive that you could explicitly declare:

#[contracttype]
#[derive(Copy, Clone, Eq, PartialEq)]
pub enum MapElement {
    Asteroid,
    FuelPod,
}

and yet when getting the bindings from the wasm it's:

#[soroban_sdk::contracttype(export = false)]
#[derive(Debug, Clone, Eq, PartialEq, Ord, PartialOrd)]
pub enum MapElement {
    Asteroid,
    FuelPod,
}

[leighmcculloch]

Only enums with integer values need the Copy derive.

See the examples here: https://soroban.stellar.org/docs/how-to-guides/custom-types#custom-type-enum

Specifically:

#[contracttype]
#[derive(Clone, Debug, Eq, PartialEq)]
pub enum Enum {
    A,
    B(...),
}

#[contracttype]
#[derive(Copy, Clone, Debug, Eq, PartialEq)]
#[repr(u32)]
pub enum Enum {
    A = 1,
    B = 2,
}

[Smephite]

I think @tyvdh's question might've been misleading here, as it is only loosely connected to the issue at hand.
Regarding custom discriminants it is true that only enum with integer values need the Copy trait, but the note by Tyler was that structs deriving Copy in their original source won't derive Copy after the wasm compile -> regenerating bindings using soroban flow.
To resolve this second issue, it is probable that a more sophisticated analysis of the provided struct is required to circumvent the already mentioned issue of the possibility of the struct containing un-copyable types.

As this seems to be only loosely connected to this issue / PR it might be suitable to open a new issue.

[Smephite]

I think @tyvdh's question might've been misleading here, as it is only loosely connected to the issue at hand. Regarding custom discriminants it is true that only enum with integer values need the Copy trait, but the note by Tyler was that structs deriving Copy in their original source won't derive Copy after the wasm compile -> regenerating bindings using soroban flow. To resolve this second issue, it is probable that a more sophisticated analysis of the provided struct is required to circumvent the already mentioned issue of the possibility of the struct containing un-copyable types.

As this seems to be only loosely connected to this issue / PR it might be suitable to open a new issue.

Another possibility could be to throw a compiler warning when trying to derive Copy on a contract_type that does not support it.

[leighmcculloch]

the note by Tyler was that structs deriving Copy in their original source won't derive Copy after the wasm compile -> regenerating bindings using soroban flow.
To resolve this second issue, it is probable that a more sophisticated analysis of the provided struct is required to circumvent the already mentioned issue of the possibility of the struct containing un-copyable types.

Ah yes, indeed. The contract specification doesn't capture third party trait implementations. We could extend the contract specification to try and capture other things like that. Something worth considering, although not without tradeoffs.

[Smephite]

I updated the PR to only add the Copy derive in the generate_enum function.

For my own understanding, I have one question regarding the Spec.

#[contracttype]
#[derive(Debug, Copy, Clone, Eq, PartialEq, Ord, PartialOrd)]
#[repr(u32)]
pub enum MyCoolType {
    ThisTypeIsSadBecauseTheNameIsTooLong = 0,
    Type = 1
}

#[contracttype]
#[derive(Debug, Clone, Eq, PartialEq, Ord, PartialOrd)]
pub enum MyNormalType {
    One(Vec<Symbol>),
    Two
}

in a rust sense both of these are enums, but when inspecting the wasm using the soroban cli the second enum is of "type": "union".
What kind of rust enums will be mapped to the soroban enum?
Is it safe to assume that every enum variant reaching generate_enum(...) will not contain an un-copyable value?