icerpc / icerpc-csharp

A C# RPC framework built for QUIC, with bidirectional streaming, first-class async/await, and Protobuf support.
https://docs.icerpc.dev
Apache License 2.0
108 stars 13 forks source link

Collections of Optional Custom Types do not Compile #3812

Closed InsertCreativityHere closed 11 months ago

InsertCreativityHere commented 11 months ago

Description

For collection types, we need to generate EncodeAction functions, and the implementation of this function depends on whether the collection is of value or reference types.

For custom types, the generated code assumes it's always backed by a reference type. If the custom type you map to is actually a value type, slicec-cs produces code that doesn't compile.

Reproduction steps

For example:

interface Pingable {}

[cs::type("IceRpc.Slice.Tests.PingableProxy")]
custom PingableProxy

compact struct MyCompactStructWithSequenceOfNullableProxies {
    i: Sequence<PingableProxy?>
}

Produces the following code:

(ref SliceEncoder encoder, IceRpc.Slice.Tests.PingableProxy? value) =>
    PingableProxySliceEncoderExtensions.EncodePingableProxy(ref encoder, value));

Instead of:

(ref SliceEncoder encoder, IceRpc.Slice.Tests.PingableProxy? value) =>
    PingableProxySliceEncoderExtensions.EncodePingableProxy(ref encoder, value!.Value));
InsertCreativityHere commented 11 months ago

Actually, I don't think this is specific to collections, even this produces uncompilable code:

compact struct MyCompactStructWithNullableProxy {
    i: PingableProxy?
}
InsertCreativityHere commented 11 months ago

I ran into this when updating the tests in icerpc-csharp to use the new interface-proxy-custom logic. Everything ran fine, except this one test: https://github.com/icerpc/icerpc-csharp/blob/main/tests/IceRpc.Slice.Tests/StructTests.Slice1.slice everything in that test produces uncompilable code.

For now, I'm just going to uncomment it.