On Sat, 11 Jan 2025 12:39:13 -0500
David Malcolm <dmalc...@redhat.com> wrote:
> I should also mention that if this is like C's #include, that we track
> includes for C/C++ in libcpp's line maps: see e.g. LC_INCLUDE and
> included_from. If you're doing this for cobol's locations, then have
> a look at diagnostic_text_output_format::report_current_module in
> gcc/diagnostic-text-format.cc which emits the header lines here:
>
> In file included from include-chain-1.h:5,
> from include-chain-1.c:30:
> include-chain-1-2.h:1:6: error: blah blah
>
> based on the data in the line maps.
HI David,
Thanks for your instant help. I'll do something with this tomorrow.
You said a mouthful in your second post. I'll try to figure out what
you mean, and otherwise use option #1.
To satisfy your curiosity, a COBOL copybook is indeed like a C include
file. The copybook text is interpolated at the point where the COPY
statement appears.
However, the intention is somewhat different. Typically a copybook has
a record definition that the program uses in a modified form. The
modification is done with
COPY copybook REPLACING X with Y
where X is a COBOL identifier, or part of one. For example, in
https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/blob/master+cobol/gcc/cobol/tests/Listing-16-8/Listing16-8.cbl?ref_type=heads
we have
COPY Copybook3 REPLACING CustKey BY NewKey.
REPLACING allows uses of the same definition with slightly
different names.
In COBOL, COPY is one of two "Text Manipulation" statement/directives
in the Compiler Directing Facility (CDF). The other is REPLACE, which
is a kind of specialized sed(1) but without regular expressions.
Implementation status
In our front end these directives are applied before Flex sees the
input, in the file-reader, lexio.cc. That's also where the
fixed-format aspects of the language are handled, so the regular
expressions in Flex don't cope with indentation and newlines.
The output of the file-reader is one big file. Like the C
preprocessor, it emits directives that the demark the boundaries of the
original files; it's up to the lexer to recognize them and update the
current filename and line number. That functionality has been working
for over a year now.
We don't have locations in the CDF yet. That's coming. It tracks
newlines and columns, but not as locations. So, work.
As of last week, the lexer is doing a decent job tracking columns, and
so now the parser does, too. The Bison parser, when it detects a syntax
error, normally flags the lookahead token, whose location we use.
Semantic errors detected in the parser actions naturally refer to some
particular token on the right side of a rule, whose location is passed
explicitly to the diagnostic function. (My favorite lately is
emit_diagnostic_valist().)
Having introduced the diagnostic framework, we instantly had 105 broken
tests, whose error text had changed. Last week I got that down to
100. Once we get over this copybook hump, I think progress will
hasten. We're going to make our tests work in situ first, before we
undertake localization or DejaGnu adaptation. Just, you know, 10 steps
at a time or so.
--jkl
