Hi all, hi Yuao,
Yuao Ma wrote:
I mostly agree it looks okay. While I'm not that meticulous about
diagnostics, I believe it should point to the '=' sign or the first
character of the expression. Pointing to the middle, however, seems a
bit odd.
Looking at your patch, I understand what you mean.
I have tried to solve the issue more properly, but started to run into
further issues.
Hence, I filed a PR to track this https://gcc.gnu.org/PR121750 with the
draft patch.
* * *
I haven't been able to figure out which part is causing the 'where' to point to
the
leading whitespace of the expression.
The problem is that gfc_current_locus points before the next character
to parse, i.e. last parsed character, if any.
For parser errors, that's an odd location, hence, I added the '+1' for
%C, which should be in nearly all cases the better location.
For gfc_code->loc, gfc_expr->where etc., the location was not
unanimously wrong, only sometimes. Thus, I have not added a '+1' there.
But it looks as if it is more often wrong than right. In a few cases,
there is already a range parsing, which should be fine, but as mentioned
in the PR, I do not dare to use a range value throughout: The current
gfc_locus is rather low weight during parsing, but when converting it to
'location_t', every location fills a slot in the line-table map and with
ranges even three (begin, end + range; and caret, but we currently have
it always match the beginning.)
And as gfortran tries different variants when matching a line (Is this a
'do' construct ["d o i = 123 + a, n"], if not, is this an assignment ["d
o i = 123 + a"], or is this ...), some of those variants will require
more parsing with fixed-form Fortran (punch-card format, spaces have no
meaning), but also with free form 'if (...)' matches successfully but
causes later fails such that only the condition inside 'if' then remains
– still adding all the ranges for 'if' seem to be too much.
* * *
Tobias,
who got distracted by looking at the diagnostic topic and will now
continue looking at the conditional-expr patch.
PS: Talking about locations, I think also in trans*.cc we can do better.
Most of the time, we currently use the code->loc location when we could
use a more-specific location.
