On 1/24/19 2:40 PM, Jakub Jelinek wrote:
Hi!
On the following testcase,
_cpp_bracket_include -> glue_header_name emits
if (token->type == CPP_EOF)
{
cpp_error (pfile, CPP_DL_ERROR, "missing terminating > character");
break;
}
which works, that last token has proper src_loc etc., but then
parse_has_include as _cpp_bracket_include caller will do cpp_get_token
(pfile) again and emit another error, which is both IMHO unnecessary when
we've emitted the earlier one, but also is a different CPP_EOF from the
earlier one and so it has uninitializer src_loc etc., so diagnostics on it
doesn't work. Looking around elsewhere in libcpp, we have in directives.c
#define SEEN_EOL() (pfile->cur_token[-1].type == CPP_EOF)
macro and if SEEN_EOL, we omit some diagnostics.
If pfile->cur_token[-1].type is CPP_EOF, we must have emitted some error
already, either the:
cpp_error (pfile, CPP_DL_ERROR,
"operator \"__has_include__\" requires a header string");
one or
cpp_error (pfile, CPP_DL_ERROR, "missing terminating > character");
otherwise pfile->cur_token[-1].type must be CPP_GREATER, CPP_STRING or
CPP_HEADER_NAME, so there is no point getting another token when we know we
are at CPP_EOF and emitting another diagnostics.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2019-01-24 Jakub Jelinek <ja...@redhat.com>
PR preprocessor/88974
* expr.c (parse_has_include): Don't cpp_get_token if EOL has been
seen.
* c-c++-common/cpp/pr88974.c: New test.
--- libcpp/expr.c.jj 2019-01-01 12:38:16.132007335 +0100
+++ libcpp/expr.c 2019-01-24 14:07:10.080774120 +0100
@@ -2238,7 +2238,9 @@ parse_has_include (cpp_reader *pfile, en
XDELETEVEC (fname);
}
- if (paren && cpp_get_token (pfile)->type != CPP_CLOSE_PAREN)
+ if (paren
+ && pfile->cur_token[-1].type != CPP_EOF
Is there a reason not to use the SEEN_EOL macro here, too (first moving
it into a header)?
Do we still give this diagnostic if there is a closing > but no )?
Jason