Changes in src/Parser/lex.ll [ba2356b:daf9671]
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
src/Parser/lex.ll
rba2356b 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.