Raise when translating generic T.class_of#558
Conversation
This `T.class_of(X)[Y]` doesn't have an equivalent in RBS yet. We should make it raise to make sure we don't silently remove it. Signed-off-by: Alexandre Terrasa <alexandre.terrasa@shopify.com>
|
|
||
| #: (Type::ClassOf type) -> void | ||
| def visit_class_of(type) | ||
| raise Error, "Unsupported type: #{type} (no RBS equivalent yet)" if type.type_parameter |
There was a problem hiding this comment.
What do you think of keeping the types that error as sig syntax, accumulate errors and display them at the end? Unproblematic types will still be translated. I think this is also closer to what's best for the end user. Since there's no equivalent they'll either have to change the type or "skip" this translation and continue migrating rest of the types.
One issue with this is that Tapioca will start erroring on files that contain such types. So I'm thinking we may want to make it raise optionally (default = raise) so Tapioca can still generate RBIs without crashing?
Do you mean Spoom or does Tapioca use it too? I think it's fine for spoom srb sigs translate to error but having that control would be nice.
|
Superseded by #570, which properly implements bidirectional support now that RBS 4.0.1 ships |
2 participants
T.class_of(X)[Y]doesn't have any equivalent in RBS.When we try to translate such a type to RBS, we just silently drop the generic type param:
I think we should start making it raise so we can catch such cases in our migration process.
One issue with this is that Tapioca will start erroring on files that contain such types. So I'm thinking we may want to make it raise optionally (default = raise) so Tapioca can still generate RBIs without crashing?