Case sensitivity fix #54 #66
Conversation
…SS keywords in lowercase and a parser that checks whether the following token is a reserved keyword.
…s, according to the specification.
…s with the EsprParser trait.
…g upper- and lowercase characters in IDs makes attribute_id recognize things that are actually redeclared_attributes.
…termination condition. This allows parsing of UNIQUE without accidentally reading keywords.
…d named_types, because by allowing uppercase and lowercase, one swallows the other.
…. This is useful when expecting a keyword in unit tests.
…any_till with many_till_reserved.
…o errors when allowing upper and lowercase characters.
… reserved keyword is found.
…rors when allowing upper and lowercase characters.
|
Could you please let me know if this pull request is acceptable? A lot of fixes I'm working on depend on the changes I've made here and it would be a shame to put more effort in to something that won't be accepted. |
|
We apologize for not responding to you earlier. |
To merge this PR requires me re-reading and understanding the ISO-10303-11 with discussed in #54, and it takes more time for review.
This pull requrest has some independent parts e.g. |
|
Thank you for your reply. As for the part on case sensitivity, the definition is under I'll try and split my pull request in to smaller pieces, but the main aim of this PR was to get case-insensitivity working, which is quite a large operation on the code base. My subsequent edits with which I managed to parse serveral APs rely on case-insensitivity unfortunately. |
|
|
This pull request fixes case sensitivity for the Express Parser in accordance with ISO-10303-11, as discussed under #54
This was achieved by restricting identifiers to anything but reserved keywords, which is defined in the standard. It also changes the order of operations for certain alt parsers, because some are implemented in a way that they take precedence over subsequent parsers if case sensitivity is ignored.