This is part of my hunt for "systemic" sources of size bloat that I can fix centrally.
Fixes here are:
In the server runtime, server impls that do not override recv_source (which is the vast majority of them!) no longer generate a runtime-unreachable panic for a closed receive failure, since they cannot actually issue a closed receive.
In the server runtime, clients that send overlong messages are now faulted without any possibility of panicking the server, removing a mostly-unreachable panic site.
In the client stubs, the return code from operations that "cannot fail" is no longer checked. This technically can miss cases where we call the wrong task (due to some sort of gross misconfiguration), but the previous check wasn't actually sufficient to detect that reliably, and was costing a panic site at every client call site.
In the client stubs, we no longer use ssmarshal/hubpack to deserialize (). Deserializing () is a no-op but still compiled in a panic, because we sliced an array to do it and the compiler couldn't tell that the value we were using to slice was (at runtime) always zero.
This is part of my hunt for "systemic" sources of size bloat that I can fix centrally.
Fixes here are:
recv_source(which is the vast majority of them!) no longer generate a runtime-unreachable panic for a closed receive failure, since they cannot actually issue a closed receive.(). Deserializing()is a no-op but still compiled in a panic, because we sliced an array to do it and the compiler couldn't tell that the value we were using to slice was (at runtime) always zero.