#464 improve diagnostics for constants

[Simon Sobisch]

Currently all constants are replaced to their values in the scanner - the parser does not "see" the constants, but literals.

This can produce some strange diagnostic messages and does not allow compilation of code that previously worked on ACU/MF (and possibly others) where level 78 constants were defined in multiple copybooks.

In this case GC raises

error: syntax error, unexpected Literal, expecting Identifier

As the parser "sees"

78  "some-literal"  VALUE "some-literal".

While MF raises a low-priority warning (we should raise it by default but allow to increase it) for duplications:

COBCH1236W Duplicate, equivalent definition of level 78 my-constant-name

and an error if the second value differs, both with a "note: ... defined here"; which we also should do.

To do so, we likely need to return a new token "constant-name" from scanner.l and use it in parser.y in the literal definition (getting its literal value out there) plus adjust the level 78 constant parsing to explicit handle that; along with a bunch of test cases.

Assigned to @lefessan as we discussed that before - feel free to assign someone else.

[Simon Sobisch]

The case of "same definition" may go with -Wredefinition. As noted, the current version of level 78 breaks with GC; if the values are not used and defined multiple times this is output as:

TEST.cob:111: warning: redefinition of 'X-CR' [-Wredefinition]
  109 |       *
  110 |        01  X-LF                            PIC  X(01) VALUE X"0A".
  111 >        01  X-CR                            PIC  X(01) VALUE X"0D".
  112 |       *
TLIB.cpy:19: note: 'X-CR' previously defined here [-Wredefinition]
   17 |            03 X-SOH                   PIC  X(01) VALUE X"01".
   18 |            03 X-LF                    PIC  X(01) VALUE X"0A".
   19 >            03 X-CR                    PIC  X(01) VALUE X"0D".
   20 |            03 X-CRLF                  PIC  X(02) VALUE X"0D0A".

In the case of redefinition (=same VALUE) of constants we can just throw away the second definition, so the use of the constant name will not create an error.