remove constraints on rules and token names

[jlguenego]

First of all, thanks for this great lib.

I have this error during the performSelfAnalysis check.

Error: Parser Definition Errors detected:
 Invalid Grammar Token name: ->ENCODING-CONTROL<- it must match the pattern: ->/^[a-zA-Z_]\w*$/<-
    at D:\formation\asn.1\node_modules\chevrotain\src\parse\parser\parser.ts:237:15
    at ASN1CstParser.PerformanceTracer.TRACE_INIT (D:\formation\asn.1\node_modules\chevrotain\src\parse\parser\traits\perf_tracer.ts:50:14)
    at ASN1CstParser.Parser.j(D:\formation\asn.1\node_modules\chevrotain\src\parse\parser\parser.ts:151:10)
    at new ASN1CstParser (D:\formation\asn.1\src\analysis\ASN1CstParser.ts:169:10)

In the ASN1 language, there are some keyword that contains a dash character (-) like for instance :

ENCODING-CONTROL
RELATIVE-OID-IRI
ABSTRACT-SYNTAX
TYPE-IDENTIFIER
MINUS-INFINITY
PLUS-INFINITY
NOT-A-NUMBER
RELATIVE-OID
TIME-OF-DAY
DATE-TIME
OID-IRI

Is there a reason for this control ?
What is the recommanded way to proceed with this kind of keyword?

You can see my library that is using chevrotain here:
https://github.com/jlguenego/asn.1

[bd82]

I think this constraint is an historic leftover which could be removed (PRs welcome 😄 ).

However the limitation is on a token's name, not what the token pattern matches.
So there is nothing stopping you from creating a ENCODING_CONTROL token which consumes "ENCODING-CONTROL" string

[jlguenego]

understood. So this is not a critical bug .
Nonetheless I am going to do this PR ... for fun 😄

[bd82]

That would be most welcome 👍

[jlguenego]

I tried to do it ;)

[jlguenego]

Just for info, I just released a website that shows ASN.1 language stuff. This website is using chevrotain behinds.
https://asn1.netlify.app/

Thanks again for this.

[bd82]

Now I finally know what ASN.1 is:

• https://en.wikipedia.org/wiki/ASN.1

I will hopefully release a new Version of Chevrotain with the fix later this week.
I will keep the issue open until then.

[bd82]

released in 7.1.0