From 45efec6f22978d18e73f7dd7be29439d16bd180c Mon Sep 17 00:00:00 2001 From: François Pottier Date: Wed, 28 Oct 2015 13:05:42 +0100 Subject: Fixed some comments. --- cparser/handcrafted.messages | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) (limited to 'cparser/handcrafted.messages') diff --git a/cparser/handcrafted.messages b/cparser/handcrafted.messages index 9d02f5d2..01416449 100644 --- a/cparser/handcrafted.messages +++ b/cparser/handcrafted.messages @@ -78,8 +78,8 @@ # quite dramatically. # Instead, we prefer to dynamically distinguish between these contexts. We do -# so in a very simple way: we give --on-error-reduce directives to Menhir (in -# the Makefile) so as to replace certain error actions with reduction actions. +# so in a very simple way: we give %on_error_reduce declarations to Menhir (in +# pre_parser.mly) so as to replace certain error actions with reduction actions. # Thus, when Menhir finds an error and whatever is on the stack can be reduced # to an expression, the automaton will reduce it to an expression. By carrying # out this extra (spurious) reduction, the automaton ends up in a state where @@ -94,7 +94,7 @@ # understand how the expression should be completed. Our error message exhibits # a bias towards ending expressions. -# OTHER USES OF --on-reduce-error: +# OTHER USES OF %on_error_reduce: # We apply this technique also to attribute_specifier_list and declarator. This # means, intuitively, that when we find an error at a position where an @@ -103,9 +103,9 @@ # into account in messages where an attribute_specifier_list or a declarator has # just been recognized. -# ABOUT STRICT VERSUS LAX INTERPRETATIONS OF --on-reduce-error: +# ABOUT STRICT VERSUS LAX INTERPRETATIONS OF %on_error_reduce: -# There are two ways in which Menhir could implement --on-reduce-error. In the +# There are two ways in which Menhir could implement %on_error_reduce. In the # strict interpretation, an extra reduction takes place only if this is the # only reduction that can take place in this state. (Thus, we do not choose # between two interpretations of the past.) In the lax interpretation, an extra @@ -122,7 +122,7 @@ # In the strict interpretation, no extra reduction is permitted here, because # two reductions are enabled. In the lax interpretation, because we have -# requested --on-error-reduce primary_expression, the second production is +# declared %on_error_reduce primary_expression, the second production is # reduced. Hence, we implicitly assume that this name forms an expression # (as opposed to a label). This is slightly inaccurate (we lose completeness) # but removes an error state that is rather unpleasant. @@ -139,8 +139,8 @@ # In another instance of this phenomemon, there is a rather tricky state, # where we have read "int f" at the toplevel, and we do not know whether this # will be a variable definition (declarator) or a function definition -# (direct_declarator). In the lax interpretation, because we have requested -# --on-error-reduce declarator, we implicitly assume this must be the +# (direct_declarator). In the lax interpretation, because we have declared +# %on_error_reduce declarator, we implicitly assume this must be the # beginning of a declarator. Again, we lose completeness (we will not suggest # that an opening parenthesis would have been accepted) but this makes our # life easier, and does not sound too bad. @@ -148,24 +148,24 @@ # Another instance is a state where we have read "enum foo". This could be a # complete enum_specifier, or it could be continued with an opening brace. If it # is complete, though, we lack static context to tell what should come after it. -# Using lax --on-error-reduce enum_specifier allows us to force a reduction, +# Using lax %on_error_reduce enum_specifier allows us to force a reduction, # (thus forgetting that an opening brace would have been permitted) and to move # to another state where more contextual information is available. As noted # above, this reduction can already take place naturally, depending on the # lookahead token, so we are only adding more cases where it takes place. -# The lax --on-reduce-error is used also to deal with a family of error states +# The lax %on_error_reduce is used also to deal with a family of error states # where we have recognized a complete statement which could be continued with an # ELSE branch. These error states are difficult to explain: although we can # definitely say that ELSE is permitted, we have difficulty telling what else is # permitted, by lack of static context. We could recover this static information # by introducing a phantom parameter on statements, but that would be heavy. We -# just cut a corner and use --on-reduce-error to view this as a complete +# just cut a corner and use %on_error_reduce to view this as a complete # statement. Thus, we abandon the possibility that the statement could be # continued with ELSE: our error message will not mention it. Again, this makes # our life easier, and does not sound too bad. -# We also apply --on-error-reduce to specifier_qualifier_list and +# We also apply %on_error_reduce to specifier_qualifier_list and # option(abstract_declarator(type_name)). This allows us to recognize # a valid type name, even when this type name could be continued. This # allows us to go back to a state where we see the opening parenthesis @@ -2622,8 +2622,8 @@ translation_unit_file: TYPEDEF INT STAR RPAREN # one more '*', possibly followed with type qualifiers. # If the pointer is finished, then we expect a direct declarator. -# If may seem tempting to declare --on-error-reduce "list(pointer1)", but -# that would clash with --on-error-reduce "abstract_declarator(type_name)". +# If may seem tempting to declare %on_error_reduce "list(pointer1)", but +# that would clash with %on_error_reduce "abstract_declarator(type_name)". # There are states where both reductions are enabled, and Menhir currently # refuses to choose between them. @@ -2659,7 +2659,7 @@ translation_unit_file: TYPEDEF INT VAR_NAME XOR_ASSIGN ## # Because attribute_specifier_list and declarator have been marked -# --on-error-reduce, we perform several spurious reductions and end up here. +# %on_error_reduce, we perform several spurious reductions and end up here. # Which is good, because the context is clear. # If the attribute_specifier_list or declarator was not finished, then we could have accepted: @@ -4633,7 +4633,7 @@ translation_unit_file: INT VAR_NAME LPAREN INT VAR_NAME RPAREN LBRACE XOR_ASSIGN ## # We are possibly at the end of a function body. # -# Note that, because we have used --on-error-reduce to consider some statements +# Note that, because we have used %on_error_reduce to consider some statements # as complete even when they could be continued ELSE, we may end up here even # though ELSE is permitted. There is nothing we can do about it. We just omit # this permitted continuation in our message. -- cgit