This PR is a first step towards refactoring our cs_type_string functions:
Currently, TypeRefExt::cs_type_string takes a TypeContext, and has 3 different behaviors depending the type-context.
This PR splits this function into 3: field_type_string, incoming_parameter_type_string, and outgoing_parameter_type_string.
The behavior is identical to before, I've just split each context's match case into a standalone function.
Note that ParameterExt has it's own function also named cs_type_string.
I will deal with this in my next PR, but wanted to split it up to keep these easy to review.
ParameterExt::cs_type_string took a bool: ignore_optional, but this was always false, so I removed the parameter and hard-coded false. Otherwise this function was left alone.
This PR is a first step towards refactoring our
cs_type_string
functions:Currently,
TypeRefExt::cs_type_string
takes aTypeContext
, and has 3 different behaviors depending the type-context. This PR splits this function into 3:field_type_string
,incoming_parameter_type_string
, andoutgoing_parameter_type_string
. The behavior is identical to before, I've just split each context's match case into a standalone function.Note that
ParameterExt
has it's own function also namedcs_type_string
. I will deal with this in my next PR, but wanted to split it up to keep these easy to review.ParameterExt::cs_type_string
took abool: ignore_optional
, but this was always false, so I removed the parameter and hard-coded false. Otherwise this function was left alone.