WIP: Operator escaping#1221
Open
let-def wants to merge 12 commits into
Open
Conversation
GC stat after
==============
parsing:
allocated_words: 37657442
minor_words: 15582165
promoted_words: 2166069
major_words: 24241346
minor_collections: 103
major_collections: 24
heap_words: 7015424
heap_chunks: 20
top_heap_words: 7015424
compactions: 0
reformatting:
allocated_words: 153497667
minor_words: 131135436
promoted_words: 36777601
major_words: 59139832
minor_collections: 553
major_collections: 41
heap_words: 9278464
heap_chunks: 22
top_heap_words: 9278464
compactions: 0
GC stat before
==============
parsing:
allocated_words: 41243812
minor_words: 19168535
promoted_words: 3911746
major_words: 25987023
minor_collections: 117
major_collections: 25
heap_words: 7015424
heap_chunks: 20
top_heap_words: 7015424
compactions: 0
reformatting:
allocated_words: 159464070
minor_words: 137101839
promoted_words: 39600932
major_words: 61963163
minor_collections: 576
major_collections: 43
heap_words: 8068096
heap_chunks: 21
top_heap_words: 8068096
compactions: 0
GC stat after
=============
parsing:
allocated_words: 35870858
minor_words: 13795581
promoted_words: 2141052
major_words: 24216329
minor_collections: 96
major_collections: 24
heap_words: 7015424
heap_chunks: 20
top_heap_words: 7015424
compactions: 0
reformatting:
allocated_words: 149597673
minor_words: 127235442
promoted_words: 36784443
major_words: 59146674
minor_collections: 539
major_collections: 42
heap_words: 395776
heap_chunks: 1
top_heap_words: 9278464
compactions: 2
Replace a global buffer by a buffer local to parsing code. This fixes a bug when processing multiple inputs. For instance with refmt a.re b.re, b.re comments will (incorrectly) be read from a buffer that begins with content from a.
prefix ! is now "not" postfix ^ is now dereferencing (instead of prefix !) infix ++ is now string concatenation (instead of infix ^) ^ now defines a family of postfix operators (^@, ^/, etc), that cannot terminates with ".". (How should existing ocaml operators be remapped?)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is another attempt at solving
https://github.com/facebook/reason/pull/909.The rules for operator escaping now:
/and*can be escaped,/*and*/have to be escaped to/\*and*\/so that they cannot be confused with comment sequence\are reintroduced (for instance,^\/in a source will be reprinted as^/because it is not ambiguous)Implementation:
*/or/*which would require a more expressive lexer generator, but a post-lexing step scan the lexeme for beginning of comments and cut the lexeme (giving back characters to the lexer)Corner cases (need to reach a consensus...):
\/*or\*/are erroneous: they are lexed as an empty operator followed by beginning / ending of comment.For instance:
\/*is lexed as\followed by/*,\is interpreted as escaping ``, so this means the empty operator.So what should this sequence mean? An erroneous beginning/ending of comment that deserve a warning or the escaped version of an operator that looks like beginning/ending of comment?