Unbalanced parentheses make compilation fail without error message

[ilpincy]

For instance:

function f(i) {
  if(i == 0) {
    log("ciao")
  }
  else {
}

[py-humanitas]

Hello,
Is there another way to access the name of the file processed than buzzlex_getfile ?
Because, I would think that having the following code in the function match (buzzparser.c) could solve the problem:

   if(!par->tok) {
      fprintf(stderr,
              "%s: Syntax error: expected %s, found nothing",
              //function to get the name of the file,
              buzztok_desc[type]);
      return PARSE_ERROR;
   }
   if(par->tok->type != type) {
      fprintf(stderr,
              "%s:%" PRIu64 ":%" PRIu64 ": Syntax error: expected %s, found %s\n",
              buzzlex_getfile(par->lex)->fname,
              par->tok->line,
              par->tok->col,
              buzztok_desc[type],
              buzztok_desc[par->tok->type]);
      return PARSE_ERROR;
   }
   else return PARSE_OK;

[ilpincy]

I'm not sure I understand the question. What's wrong with buzzlex_getfile()? Where would you add the above code, and why does it solve the problem?

[py-humanitas]

Sorry, I should have put more explanation.

I think the unbalanced parenthesis make the compilation fail without error message because in the current code when you finish parsing the else, you check if the token matches BUZZTOK_BLOCKCLOSE (buzzparser.c:line 480) but there is no more token and thus, in the function match (buzzparser.c:line 333) we end in the case !par->tok which returns PARSE_ERROR without any message.

That's why, I think that by printing an error message in the case there is no more token, the compilation would not exit without a message anymore (the code I sent would replace the current match function code).

The reason I asked about an other way than buzzlex_getfile() is that for the message it would be useful to have the file in which the failure happened but when I use buzzlex_getfile() I get a segmentation fault (I think it happens because the last lexer is removed at the same time as the last token but I may be using it the wrong way).

[ilpincy]

Finally got some time to look into this bug. Yes, your analysis is correct! Finding a workaround...