Right now, every syntax error is fatal, we cannot report multiple syntax errors. This is really vague but below is a list of some errors which don't need to be lethal to the parser.
[ ] parse (& lower) all other modules part of the module tree. this means we need to register external modules during parsing, so we can handle them (in parallel or after parsing the original file irrespective of whether it parses (and lowers) successfully)
[x] don't bail out early when encountering undefined (nullary) attributes (fixed in c774b0ddabb3ccef7d8522f12ff75a5441ea2b95)
[x] report all instances of number literals that are "out of range" (fixed in e2d2897b074005c2852154dbae334f16b931116e) (note: the concept of number suffixes does not exist anymore, thus this error cannot happen anymore)
[ ] syntactically allow missing definitions (= + expression) in let/ins (and disallow them in the lowerer)
[x] syntactically allow weird explicit definition (= + expression) for constructors (and gate them in the lowering stage)
[ ] skip/report all instances of commas (#65, #63)
[ ] skip/r.a.i.o. unexpected ->s
[ ] r.a.i.o. invalid identifiers (consecutive dashes, trailing dashes, …) / treat them as valid identifiers; needs lexer support: they should just be lexed as InvalidIdentifiers
[ ] r.a.i.o. invalid number literals (consecutive primes, trailing primes, …) / treat them as valid ones; needs lexer support: they should be lexed as InvalidNumberLiterals
[ ] all other kinds of syntax errors: t.b.d. (major!)
[ ] (maybe, not sure if worth the effort) in some cases where we expect a line break (e.g. after = in module and data declarations), we could either insert one
or skip everything until the next line break and continue parsing (but still report an error later in both case)
[ ] (maybe, not sure if worth the effort) if a parsing error occurs inside of an attribute, skip until ending ) (if exists) and continue
parsing the item or other attributes (still reporting the error). pretty sure this leads to many weird parsing errors though when trying to parse the item
Right now, every syntax error is fatal, we cannot report multiple syntax errors. This is really vague but below is a list of some errors which don't need to be lethal to the parser.
=+ expression) in let/ins (and disallow them in the lowerer)=+ expression) for constructors (and gate them in the lowering stage)->sInvalidIdentifiersInvalidNumberLiterals=in module and data declarations), we could either insert one or skip everything until the next line break and continue parsing (but still report an error later in both case))(if exists) and continue parsing the item or other attributes (still reporting the error). pretty sure this leads to many weird parsing errors though when trying to parse the itemRelated: #13.