Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed
  • src/Parser/parser.yy

    r9059213 rfaddbd8  
    1010// Created On       : Sat Sep  1 20:22:55 2001
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Wed Oct 19 22:19:33 2016
    13 // Update Count     : 2003
     12// Last Modified On : Wed Oct  5 14:10:46 2016
     13// Update Count     : 2002
    1414//
    1515
     
    278278//
    279279// Cforall compounds this problem by introducing type names local to the scope of a declaration (for instance, those
    280 // introduced through "forall" qualifiers), and by introducing "type generators" -- parameterized types.  This latter
     280// introduced through "forall" qualifiers), and by introducing "type generators" -- parametrized types.  This latter
    281281// type name creates a third class of identifiers that must be distinguished by the scanner.
    282282//
    283283// Since the scanner cannot distinguish among the different classes of identifiers without some context information, it
    284 // accesses a data structure (TypedefTable) to allow classification of an identifier that it has just read.  Semantic
    285 // actions during the parser update this data structure when the class of identifiers change.
     284// accesses a data structure (the TypedefTable) to allow classification of an identifier that it has just read.
     285// Semantic actions during the parser update this data structure when the class of identifiers change.
    286286//
    287287// Because the Cforall language is block-scoped, there is the possibility that an identifier can change its class in a
     
    289289// particular declaration, each declaration is itself a scope.  This requires distinguishing between type names that are
    290290// local to the current declaration scope and those that persist past the end of the declaration (i.e., names defined in
    291 // "typedef" or "otype" declarations).
     291// "typedef" or "type" declarations).
    292292//
    293293// The non-terminals "push" and "pop" derive the empty string; their only use is to denote the opening and closing of
     
    431431field_name:
    432432        no_attr_identifier
    433                 // x.1, x.[0, 0.0]
    434433        | INTEGERconstant
    435434        ;
     
    27242723        | multi_array_dimension type_specifier
    27252724                { $$ = $2->addNewArray( $1 ); }
    2726 
    27272725        | '[' ']' new_identifier_parameter_ptr
    27282726                { $$ = $3->addNewArray( DeclarationNode::newArray( 0, 0, false ) ); }
Note: See TracChangeset for help on using the changeset viewer.