https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119520
Simon Sobisch <simonsobisch at gnu dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WORKSFORME |FIXED
--- Comment #2 from Simon Sobisch <simonsobisch at gnu dot org> ---
checking with the given example program and gcobol debian package from
yesterday "directly":
TYPEDEF.cob:5:37: error: USAGE TYPENAME is not ISO syntax, requires -dialect mf
5 | 01 SOME-GID USAGE INT VALUE ZERO.
| ^
TYPEDEF.cob:8:8: error: cannot MOVE '77' (FldLiteralN) to 'SOME-GID' (Fld)
8 | move 77 to some-gid.
| ^
cobol1: error: failed compiling TYPEDEF.cob
For improved error handling I'd recommend to leave the first error in, but to
internally still apply the typedef - which would prevent strange follow-up
errors like the second one (there are likely much more in bigger programs).
The example though is something else: it is when dropping the TYPEDEF line. And
this does not abort any more (same result w/wo the dialect):
TYPEDEF.cob:5:37: error: DATA-ITEM 'INT' not found
5 | 01 SOME-GID USAGE INT VALUE ZERO.
| ^
TYPEDEF.cob:8:8: error: cannot MOVE '77' (FldLiteralN) to 'SOME-GID' (Fld)
8 | move 77 to some-gid.
| ^
cobol1: error: failed compiling TYPEDEF.cob
To improve error handling here (that will help for a lot of other cases as
well!): look at the VALUE clause, if numeric then fallback to UNSIGNED
BINARY-DOUBLE, if alpanumeric/national/utf8 then PIC X/N/U of necessary size.
... and speaking of that (@jklowden you may want to move some or all of those
suggestions out to a feature request ticket of the priority you think is
reasonable): when dropping the definition for some-gid the result is:
TYPEDEF.cob:8:19: error: DATA-ITEM 'some-gid' not found
8 | move 77 to some-gid.
| ^
TYPEDEF.cob:8:19: error: invalid receiving operand
TYPEDEF.cob:9:11: error: DATA-ITEM 'SOME-GID' not found
9 | if SOME-GID = 77 then
| ^
TYPEDEF.cob:12:32: error: DATA-ITEM 'some-gid' not found
12 | display "the GID is " some-gid ", boo!".
| ^
cobol1: error: failed compiling TYPEDEF.cob
cc1 would only error the first time, then stays silent about that identifier
(and don't calculate it in -fmax-errors).
One way to do this is to internally create a data-item with that name, similar
to the one above; that still allows checking for type mismatches later on, for
example, and would also work around other issues like the following:
TYPEDEF.cob:8:19: error: DATA-ITEM 'some-gid' not found
8 | move 77 to some-gid.
| ^
TYPEDEF.cob:8:19: error: invalid receiving operand
compilation terminated due to -fmax-errors=2.
(that is one error, but currently counted as two)
