feat (parser): parse empty CLASS-ID paragraph with "unimplemented" warning

[kmr-srbh]

• Add support for parsing an "empty" CLASS-ID paragraph with no contained paragraphs and divisions.
• Emit a "unimplemented" warning and exit.

[kmr-srbh]

@GitMensch @nberth could you please review?

[nberth]

Very good! One side question though (please ignore if you have discussed this with @GitMensch already): I would have though this kind of changes for OOP would target the gitside-master branch (so GnuCOBOL 4.x instead of GnuCOBOL 3.x).

[GitMensch]

@nberth the plan is to bring the syntax and possibly first AST into GC3 so its parser is not trashed when OO is fed into it - returning UNSUPPORTED, then bringing that with a merge over to master/trunk where the AST is finished (by that also the syntax checks which may be not complete in 3.x) and the codegen is implemented. If I don't misremember, then that was also outlined in the GSoC proposal. Thanks for the reviews, I'll get in when you feel the use of that. Nicolas Berthier ***@***.***> schrieb am Freitag, 10. April 2026 um 16:20:

…

@nberth commented on this pull request. Very good! One side question though (please ignore if you have discussed this with @GitMensch already): I would have though this kind of support would target the `gitside-master` (so GnuCOBOL 4.x instead of GnuCOBOL 3.x). In tests/testsuite.src/syn_definition.at: > @@ -2947,3 +2947,19 @@ AT_DATA([prog.cob], [ AT_CHECK([$COMPILE_ONLY -Wno-unfinished prog.cob], [0], [], []) AT_CLEANUP + Minor: we typically put two empty lines below an `AT_CLEANUP`. In tests/testsuite.src/syn_definition.at: > @@ -2947,3 +2947,19 @@ AT_DATA([prog.cob], [ AT_CHECK([$COMPILE_ONLY -Wno-unfinished prog.cob], [0], [], []) AT_CLEANUP + +AT_SETUP([CLASS-ID Syntax Check]) +AT_KEYWORDS([CLASS-ID]) + +AT_DATA([prog.cob], [ + IDENTIFICATION DIVISION. + + CLASS-ID. MyClass. + END CLASS MyClass. + +]) I think it may be worth adding additional tests here: - One with two definitions of a class with the same name (to trigger the redefinition error); - One where the class name that follows `END CLASS` does not correspond to the current `CLASS-ID`. (Besides, the empty lines are not necessary in the COBOL code.) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[GitMensch]

Is there a reason to go on with the PR or should we just close it in favor of #287?

[nberth]

Is there a reason to go on with the PR or should we just close it in favor of #287?

I would be in favor of breaking this work into small chunks for smaller diffs that stay consistent and focused on specific bits of the syntax, so this PR is still relevant in my opinion.
Or would you rather have a final big commit with most OO syntax and tests for syntax checks? In which case it may still make sense to have a temporary target oo-for-gnucobol-3.x branch from which we derive one big svn commit at the end.

[GitMensch]

looks good for a baseline; a bit more and we could upstream the first part (as soon as FSF papers are done, which currently seems to take some more time on their side), if you both think that's useful

[kmr-srbh]

Can we add the new branch oo4gnucobol-3.x to the CI workflow? Happy to push a commit for that.

[nberth]

Very good. I think we're almost there. Only a minor suggestion to improve message order.

[nberth]

I think that's a proper basis to build upon for the subsequent syntactic constructs, so we can merge into our staging oo4gnucobol-3.x branch.

Great job!

(The CI failures seem unrelated to your changes, so I'll merge as is).