Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metarpheus fails when an unexpected scala type is found #91

Open
calippo opened this issue Jan 3, 2020 · 3 comments
Open

Metarpheus fails when an unexpected scala type is found #91

calippo opened this issue Jan 3, 2020 · 3 comments
Assignees
Labels

Comments

@calippo
Copy link
Member

calippo commented Jan 3, 2020

private[extractors] def tpeToIntermediate(tpe: Type): intermediate.Type = tpe match {

The referenced match is not exhaustive. I'm sure it breaks up on Type.Repeated (MyType*), but it looks pretty fragile.

@calippo calippo self-assigned this Jan 3, 2020
@calippo
Copy link
Member Author

calippo commented Jan 3, 2020

I see two options:

  1. we add a case for Type.Repeated. I don't really think we need it, and there might be other situations where the match fails.
  2. we modify metarpheus so that types that are not explicitly handled are just skipped (maybe logging a warning message)

@gabro what you think?

@calippo calippo changed the title Metarpheus fails when an unmatched scala type is found Metarpheus fails when an unexpected scala type is found Jan 3, 2020
@calippo
Copy link
Member Author

calippo commented Jan 14, 2020

@tpetrucciani what you think about this?

@tpetrucciani
Copy link
Contributor

That match is definitely fragile, but that's because we only support a few forms of types. However, ignoring unsupported types instead of failing sounds slightly risky: we will get arguably invalid models (albeit with a warning).

What's the scenario in which the current behaviour is problematic?

I suppose one problem is that, currently, I think we are converting types via tpeToIntermediate before we discard unused models via stripUnusedModels. So we might fail because of an unsupported type even though it wouldn't appear in the final model anyway. If that's the case, we could try to invert these two steps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants