Changeset daf9671 for src/Parser/lex.ll
- Timestamp:
- May 24, 2017, 5:36:41 PM (7 years ago)
- Branches:
- ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
- Children:
- 3c0ec68
- Parents:
- 678765c
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
src/Parser/lex.ll
r678765c rdaf9671 10 10 * Created On : Sat Sep 22 08:58:10 2001 11 11 * Last Modified By : Peter A. Buhr 12 * Last Modified On : Thu May 18 09:03:49201713 * Update Count : 5 1312 * Last Modified On : Mon May 22 07:46:30 2017 13 * Update Count : 525 14 14 */ 15 15 … … 377 377 "?"{op_binary_over}"?" { IDENTIFIER_RETURN(); } // binary 378 378 /* 379 This rule handles ambiguous cases with operator identifiers, e.g., "int *?*?()", where the string "*?*?" 380 can be lexed as "*"/"?*?" or "*?"/"*?". Since it is common practise to put a unary operator juxtaposed381 to an identifier, e.g., "*i", users will be annoyed if they cannot do this with respect to operator382 identifiers. Even with this special hack, there are 5 general cases that cannot be handled. The first383 case is for the function-call identifier "?()":384 385 int * ?()(); // declaration: space required after '*' 386 * ?()(); // expression: space required after '*'387 388 Without the space, the string "*?()" is ambiguous without N character look ahead; it requires scanning389 ahead to determine if there is a '(', which is the start of an argument/parameter list.390 391 The 4 remaining cases occur in expressions: 392 393 i++?i:0; // space required before '?' 394 i --?i:0; // space required before '?'395 i?++ i:0; // space required after '?'396 i?--i:0; // space required after '?' 397 398 In the first two cases, the string "i++?" is ambiguous, where this string can be lexed as "i"/"++?" or 399 "i++"/"?"; it requires scanning ahead to determine if there is a '(', which is the start of an argument 400 list. In the second two cases, the string "?++x" is ambiguous, where this string can be lexed as 401 "?++"/"x" or "?"/"++x"; it requires scanning ahead to determine if there is a '(', which is the start of402 an argument list.379 This rule handles ambiguous cases with operator identifiers, e.g., "int *?*?()", where the string "*?*?" can be 380 lexed as "*?"/"*?" or "*"/"?*?". Since it is common practise to put a unary operator juxtaposed to an identifier, 381 e.g., "*i", users will be annoyed if they cannot do this with respect to operator identifiers. Therefore, there is 382 a lexical look-ahead for the second case, with backtracking to return the leading unary operator and then 383 reparsing the trailing operator identifier. Otherwise a space is needed between the unary operator and operator 384 identifier to disambiguate this common case. 385 386 A similar issue occurs with the dereference, *?(...), and routine-call, ?()(...) identifiers. The ambiguity 387 occurs when the deference operator has no parameters, *?() and *?()(...), requiring arbitrary whitespace 388 look-ahead for the routine-call parameter-list to disambiguate. However, the dereference operator must have a 389 parameter/argument to dereference *?(...). Hence, always interpreting the string *?() as * ?() does not preclude 390 any meaningful program. 391 392 The remaining cases are with the increment/decrement operators and conditional expression: 393 394 i++? ...(...); 395 i?++ ...(...); 396 397 requiring arbitrary whitespace look-ahead for the operator parameter-list, even though that interpretation is an 398 incorrect expression (juxtaposed identifiers). Therefore, it is necessary to disambiguate these cases with a 399 space: 400 401 i++ ? i : 0; 402 i? ++i : 0; 403 403 */ 404 {op_unary}"?"({op_unary_pre_post}|" [?]"|{op_binary_over}"?") {404 {op_unary}"?"({op_unary_pre_post}|"()"|"[?]"|{op_binary_over}"?") { 405 405 // 1 or 2 character unary operator ? 406 406 int i = yytext[1] == '?' ? 1 : 2;
Note: See TracChangeset
for help on using the changeset viewer.