Preprocessor error: missing terminating ' character

[Dave-Allured]

Requirements

• Reviewed ESMF User's Guide
• Searched GitHub Discussions

Affiliation(s)

NOAA & University of Colorado

ESMF Version

8.8.1

Issue

Building ESMF 8.8.1 with clang-11 on Mac gives several errors like the following. I shortened paths for clarity. I also omitted the "tr" preprocessing sequence used with ESMF cppF90, because these errors are erupting on the first clang pass before "tr".

clang -E -P -x c -I/*/src/include /*/src/Infrastructure/Field/src/ESMF_FieldEmpty.cppF90
/*/src/Infrastructure/Field/src/ESMF_FieldEmpty.cppF90:4406:14: error: missing terminating ' character
  ! Get field's current status

This is a perfectly legal fortran 90 comment line. To me, this looks like an obvious preprocessor error.

Clang-16 compiles this file with no problem. I could force the more modern clang, but I wonder if someone with CPP experience (not me!) could suggest a more universal or elegant way of guiding the preprocessor to not break on fortran comments like this. I would hate to tamper with the actual high-quality comments in the fortran code.

Anyway, this also serves as notice in case someone else runs into the same errors.

[EDIT: Corrected the source file name above to ESMF_FieldEmpty.cppF90. Lines in the original build log were out of order due to parallel build.]

Autotag

@oehmke

[Dave-Allured]

FWIW, I scanned the whole 8.8.1 source bundle. It looks like ESMF_FieldEmpty.cppF90 is the only cppF90 file with lines that trigger this error.

[Dave-Allured]

Oh, this is a little different than what I first thought. Both clang versions (11 and 16) complain about missing terminating character. However, clang16 is treating this as a warning, not an error, thus the build succeeds. I will take a closer look at the warn vs. error controls in the clang11 build.

Meanwhile it would still be nice if the fortran preprocessor does not do this.

[oehmke]

Thanks for looking into this! Strange that clang has an issue with this comment. It looks like it’s been in there for 6 months, so it’s not a recent thing.

…

On May 6, 2025, at 10:40 AM, Dave Allured ***@***.***> wrote: Oh, this is a little different than what I first thought. Both clang versions (11 and 16) complain about missing terminating character. However, clang16 is treating this as a warning, not an error, thus the build succeeds. I will take a closer look at the warn vs. error controls ini the clang11 build. Meanwhile it would still be nice if the fortran preprocessor does not do this. — Reply to this email directly, view it on GitHub <#400 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6A7UYQBZMUI3AHS3MD4RD25DQWXAVCNFSM6AAAAAB4P46UEOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMBVGI2TQMQ>. You are receiving this because you were mentioned.

[Dave-Allured]

in there for 6 months

This has probably been going on for years. I suspect all clang versions are doing this, it's just that the warnings have always been covered up in one way or another.

I only caught this on MacPorts because it broke a build for a very old MacOS version that used clang 11 instead of clang16. My guess is that this was changed from error to warning, somewhere in the clang series, but I have not confirmed.

I can hack around this, so this is low priority. I just thought that ESMF developers should know about "another" cppF90 quirk.

Ultimately this speaks to the rather sorry state of fortran preprocessing, also witnessed by that "tr" kludge that is mentioned in ESMF preprocessing docs. I wish we had a mainstream well-behaved fortran preprocessor; but modern convention seems to be use CPP, and work around the quirks.

[Dave-Allured]

All things considered, I decided that rewording comments in the single source file is the fastest and least disruptive solution. PR submitted: #405

[oehmke]

That makes sense. I’ll take a look and see if we can get this in soon. Thanks for putting together the PR with the fix!

…

On May 6, 2025, at 12:54 PM, Dave Allured ***@***.***> wrote: All things considered, I decided that rewording comments in the source file is the fastest and least disruptive solution. PR submitted: #405 <#405> — Reply to this email directly, view it on GitHub <#400 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6A7U2NID3T2AJWWX4W7ED25EAMZAVCNFSM6AAAAAB4P46UEOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMBVGM4DSNA>. You are receiving this because you were mentioned.

[oehmke]

I just merged your PR with the fixes. Thanks again for putting those in!