Improves Primitive Types

[montymxb]

Closes #482 and Closes #199, by improving the primitive types present in Langium. In particular, this PR adds the bigint built-in type, along with an associated default value converter.

In addition:

• date was changed to Date to match the casing in typescript.
• error messages for primitive types were updated to include bigint and Date
• added default value converter for Date
• modified existing tests to incorporate bigint and Date primitives
• added new tests to enforce parsing/conversion behavior

There are some key points to note with this PR:

• It is not recommended to parse date strings directly via the Date() constructor, but I have this in place for now as a proof of concept. I think it may be worth a little bit more work to recognize only ISO 8601 strings, or RFC 2822, a combination of the two, or some other approach that is safer. It could be as simple as deconstructing the date components and using another constructor on the Date object instead.

• Booleans are still kind of odd, given that the values are either true for a successful parse or undefined, rather than true and false. In the token builder tests, I noticed a test that builds a grammar that tries to capture a false value incorrectly. Specifically,

  terminal BOOLEAN returns boolean: /true|false/;
  

  Which can parse both true and false to produce a value of true. If you try to remove false from the regex to only recognize true, you run into the awkward situation of being unable to distinguish between false and a failed parse.

  Ultimately, my thought is whether I should expand this PR to allow boolean assignments to have the expected true/false values, instead of true/undefined.

• Recognizing bigints is a little tricky, and so I've attempted to provide good examples in the tests of how this can be done properly. Lookahead and terminal ordering are both important to disambiguate between ints and bigints. Beyond that, they actually work pretty well!

[msujew]

@montymxb Small remark: With the merge of #469, boolean AST properties are always initialized with false instead of undefined.

[montymxb]

Ah, thanks for pointing that out @msujew ! Rebased on current work to get those changes in.

The standard ?= case looks good. However, a prop of a mixed type that includes a bool in the union will still resolve to undefined instead of false.

Correct me if I'm wrong here, but based on what I've seen I think actively setting of the value to false when the ?= operator is used, and the following parse fails, could resolve this particular case?

[msujew]

@montymxb I guess the meta data generator for that is too strict. On the other hand, a union with a boolean property is quite weird from a parsing perspective IMO.

Correct me if I'm wrong here, but based on what I've seen I think actively setting of the value to false when the ?= operator is used, and the following parse fails, could resolve this particular case?

I will correct, since you are wrong ;-) The issue is that we don't know whether we will parse the ?= assignment, since it's usually optional. The AST builder inside of the parser has actually no real clue about the grammar at all, and doesn't know whether any ?= assignments belong to a certain AST node. That's why we ask the AstReflection later whether we've missed something during parsing:

https://github.com/langium/langium/blob/d5ab9378f5744abe5f7827f729e35e7ebd846e1b/packages/langium/src/parser/langium-parser.ts#L273-L283

[montymxb]

Thanks for clarifying that point @msujew . With that in mind, I can focus on the Date aspect instead.

[montymxb]

Thought about Date for awhile, and have decided to leave it as is. Trying to predict what the desired Date string format should be is unclear at best, as it may vary from case to case, and region to region. ISO 8601 still seems like a good choice, but I think it's best to leave targeted conversions up to the implementer, and go with the default for now.

[spoenemann]

I think these two cases are not necessary because they are already handled by the return type below.

[montymxb]

Yeah they're not critical, I can take them out. If they're desired for some reason, it would be easy to add them in later.

I figured they might be nice for shorter terminals, like terminal BIGINT: INT instead of writing out terminal BIGINT returns bigint: INT; based on what we have already for INT. Since the same can be expressed with the return type, they don't add any expressiveness, just a shorthand equivalent.

[spoenemann]

This fixes #199 as well, right?

[montymxb]

@spoenemann yep! This PR closes #199 as well 👍