Changeset daf9671 for src/Parser/lex.ll


Ignore:
Timestamp:
May 24, 2017, 5:36:41 PM (7 years ago)
Author:
Peter A. Buhr <pabuhr@…>
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
Message:

change lexing of multiply operator identifier

File:
1 edited

Legend:

Unmodified
Added
Removed
  • src/Parser/lex.ll

    r678765c rdaf9671  
    1010 * Created On       : Sat Sep 22 08:58:10 2001
    1111 * Last Modified By : Peter A. Buhr
    12  * Last Modified On : Thu May 18 09:03:49 2017
    13  * Update Count     : 513
     12 * Last Modified On : Mon May 22 07:46:30 2017
     13 * Update Count     : 525
    1414 */
    1515
     
    377377"?"{op_binary_over}"?"  { IDENTIFIER_RETURN(); }                // binary
    378378        /*
    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 juxtaposed
    381           to an identifier, e.g., "*i", users will be annoyed if they cannot do this with respect to operator
    382           identifiers. Even with this special hack, there are 5 general cases that cannot be handled. The first
    383           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 scanning
    389           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 of
    402           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;
    403403        */
    404 {op_unary}"?"({op_unary_pre_post}|"[?]"|{op_binary_over}"?") {
     404{op_unary}"?"({op_unary_pre_post}|"()"|"[?]"|{op_binary_over}"?") {
    405405        // 1 or 2 character unary operator ?
    406406        int i = yytext[1] == '?' ? 1 : 2;
Note: See TracChangeset for help on using the changeset viewer.