On Sat, 2025-01-11 at 12:32 -0500, David Malcolm wrote:
> On Fri, 2025-01-10 at 15:52 -0500, James K. Lowden wrote:
> > What should I do with the following message?
> >
> > cobol1: warning: depth line copybook filename
> > ----- ---- --------------------------------------
> > --
> > --------
> > cobol1: warning: 1 1 prog.cob
> > cobol1: warning: 2 1 copy1.CPY
> > cobol1: warning: 3 1 copy2.CPY
> > cobol1: warning: 4 1 copy3.CPY
> > cobol1: error: copy3.CPY:1: recursive copybook: 'copy1.CPY'
> > includes
> > itself
> >
> >
> > A COBOL copybook is similar to a C include file, but cannot include
> > itself, even indirectly. That's the rule. There's no form of
> > "include
> > guard".
> >
> > (There's good reason. The Compiler Directing Facility (CDF)
> > supports
> > text substitution on the copybook, so that the same input may have
> > names with different prefixes, say, in different programs.)
> >
> > No rule says the compiler must tell the user the route to copybook
> > recursion, but I'll bet it's not controversial.
> >
> > As of now, the warning messages are sent straight to fprintf(3),
> > and
> > only the error goes to emit_diagnostic_valist(). Or will, after I
> > sort out locations within the CDF.
>
> Assuming that there's some kind of directive in cobol where a
> directive
> on a line in one file triggers the inclusion of another file (rather
> like #include directives), there are a couple of ways you could
> implement this within the existing GCC diagnostic framework.
>
> (1) error with followup notes
> =============================
>
> Something like this pseudo-code:
>
> {
> auto_diagnostic_group d;
> error (loc_of_include, "recursive copybook: %qs includes itself",
> name);
> for (auto iter : the loop of copybooks)
> inform (iter[loc], "%qs includes %qs here", iter[name_a],
> iter[name_b]);
> }
>
> which ought to emit something like:
>
> copy3.CPY:1: error: recursive copybook: 'copy1.CPY' includes itself
> (quoted source)
> ^~~~~~~~~~~~~~~
> prog.cob:1: note: 'prog.cob' includes 'copy1.CPY' here
> (quoted source)
> ^~~~~~~~~~~~~~~
> copy1.CPY:1: note: 'copy1.CPY' includes 'copy2.CPY' here
> (quoted source)
> ^~~~~~~~~~~~~~~
> copy2.CPY:1: note: 'copy2.CPY' includes 'copy3.CPY' here
> (quoted source)
> ^~~~~~~~~~~~~~~
> copy3.CPY:1: note: 'copy3.CPY' includes 'copy1.CPY' here
> (quoted source)
> ^~~~~~~~~~~~~~~
>
> ...if you see what I mean, showing the directives in their files,
> quoting the source to the user. The user's IDE can probably knows
> how
> to deal with this format, and can respond to clicks on the notes to
> take the user to the pertinent places in the code.
>
> maybe with a trailing
>
> copy3.CPY:1: note: 'copy1.CPY' was already included by 'prog.cob'
>
> or somesuch.
>
>
> (2) error with diagnostic path
> ==============================
>
> GCC diagnostics can have a "diagnostic_path" associated with them.
> Up
> to now, these have always referred to paths of execution through the
> code, but it *might* make sense to use this facility here, which
> would
> capture the chain in a structured way in SARIF output. That said, I
> looked briefly at doing this, and the existing presentation code
> makes
> so many assumptions that these are "events", and it's also somewhat
> fiddlier to implement. Hence I recommend the approach (1) above
> instead.
>
>
> I suppose there's also:
>
> (3) error with text art diagram
> ===============================
>
> If you wanted to get really fancy, there's text_art::tree_widget for
> drawing ASCII/unicode art of hierarchical data structures. But such
> diagrams should be used very sparingly, and it's probably a no-no
> here
> for accessibility reasons; although it might look cool I think (1) is
> superior here from a UX perspective.
>
>
> Hope this is helpful
> Dave
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.
Dave
