On Mon, Sep 1, 2025 at 6:58 PM Tobias Burnus <tbur...@baylibre.com> wrote: > > Yuao Ma wrote: > > BTW, The current trunk seems to have some problems with diagnostic > > location: https://godbolt.org/z/bcrvn9xo4 > > In the last days, there were some diagnostic changes; possibly > those caused an intermittent issue? > > Otherwise, it looks ok. Namely: > > The '1' points to the space after '='in 'square = "42"', > which seems to be a reasonable location for the error: > "Error: Cannot convert CHARACTER(2) to INTEGER(4) at (1)". > > A nicer output would be '~~~~~~~1–––––' with '1' under '=' > and '~~~' going from 'square...' to '...42"', but the current > one seems to be sufficient. >
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. When I started fixing the problem, mostly with cond-expr, I've noticed that gfc_gobble_whitespace is called in many places, such as when parsing level_1 expression or when matching ' %e'. I haven't been able to figure out which part is causing the 'where' to point to the leading whitespace of the expression. When it comes to the diagnostic printing, I don't quite understand why %C needs an offset of +1 but %L doesn't. In the first email of the series, I posted the diagnostics for the conditional expression; do those look acceptable? If not, I'll continue working on them. Aside from the diagnostics and cond-arg support, I think the patch itself is kind of complete now : ) > > PS: I think there is room for improvement in gfortran in general > regarding the column data - both were '1' points to - and adding > more ranges. Admittedly, range support is relatively new in gfortran. > > Additionally, parsing support is old and we have not always > ensured that the location points to the most sensible place > instead of just somewhere in the expression. But we should at least > try to improve both old output and when adding new features. > > Note: in dg-error/dg-warning, if you start the reg-expr string with, > e.g., '12:' it means that the '1' is expected in column 12, > i.e. the column shown for '<file>:<line>[.<col>]:'. That's often > not needed but if you want to make sure that the column position > is correct, you can use it in the testcase. > > We could also add fancier testcases, checking for the '~~~~1~~~~~' > but that's more effort, which in general it not worthwhile. >
