Non-exhaustive match

[jambudipa]

What does the error, "Non-exhaustive match" mean?

When I run the script to generate TS types, I receive this error, although using the getBaseCstVisitorConstructor()-derived class in code causes no problems.

If I knew what it meant, perhaps I could fix it! Is it necessary for the parser to have a rule for every token? Some of them are obviously terminal and are not intended to be parsed directly.

[msujew]

Hey @jambudipa,

this seems to be an error in Chevrotain, the non-exhaustive match errors appear when doing some internal pattern matching. See here for an example. These usually shouldn't happen though. Can you share a reproducible example for this?

[jambudipa]

I am using the latest version, yes.

If it’s working for you, perhaps I need to look at how my code is organised, since my productions is exported amongst other things in the module, might be some conflict going on.

Thanks so much for your help, I will get back to you to let you know how I get on, probably not til tomorrow now.

[bd82]

I suspect that instead of providing code snippets, a reproducing repo with step by step instructions may be needed
to enable farther debugging.

[jambudipa]

Ok, so I reorganised the code and it is now producing the types 🎉 thanks @msujew and @bd82

Follow-up question: how do I use them? 🤣 They are the results of the visitor methods, but since I am determining the shape of those results, am I responsible for ensuring those results conform to the types?

If so, why does the generateCstDts() not examine the visitor rather than the parser to determine the shapes of the types to generate?

[jambudipa]

Aha, got that wrong. They don't correspond to the visitor types...so where might I use them?

[bd82]

The generateCstDts() types describe the data structure (CST) automatically generated by Chevrotain during parsing.

The visitor traverses this data structure and outputs your own custom data structure.