RE: --synclines adds #line 4711 after #define xyz(abc) ...\

[Kadlec, Albrecht]

FSF copyright is Ok for me, I've been contributing to free software before 
(fvwm2 & emacs/gnus).
For my company, it's in the mutual interest as well.

Well, I'd do the sensible thing and reduce the amount of #line output - and 
especially suppress it after line-continuation backslashes, where it's 
disrupting the sematic of that continued statement (c/c++/makefiles, ....)

Since --synclines is already an opt-in feature, I don't see it as a huge 
problem to reduce the number of inserted #line directives to a reasonable level 
(i.e. less spamming of multi-line expansions, but rather a 'reset line number' 
after the block - at least that's what the C preprocessor & similar tools do - 
I have bene writing Compilers for DSPs for a decade).

Worst case, we could extend the --syncline parameter with an optional 
'=feature-set' part:
--syncline=feature1,feature2,....

e.g.: 
--syncline=line-continuation to switch on line-continuation-awareness 
        That could get an own '=\', if other line-continuation characters 
surface for other languages.
--syncline=commentstart=/*,commentend=*/  to suppress the emission within 
multi-line C comments /* ... */

So my C/makefile use cases would be covered by --syncline= 
line-continuation,commentstart=/*,commentend=*/
Maybe allow abbreviations: --syncline= lc,cs=/*,ce=*/
Maybe add an M4OPTIONS environment variable for defaults?

What is the qualification process for a submission?
Is there an official acceptance-test / review process or is there a test suite 
to pass?

Cheers,
Albrecht

-----Original Message-----
From: Eric Blake <eblake@redhat.com> 
Sent: Wednesday, May 26, 2021 5:10 PM
To: Kadlec, Albrecht <Albrecht.Kadlec@elektrobit.com>
Cc: bug-m4@gnu.org
Subject: Re: --synclines adds #line 4711 after #define xyz(abc) ...\

CAUTION: This email originated from outside of the Elektrobit organization. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.


On Sat, Dec 26, 2020 at 06:26:42PM +0000, Kadlec, Albrecht wrote:
> Hi,
>
> We are using GNU m4 1.4.18:  are there any plans for extensions a'la a 
> c-mode via -synclines=c,'#line __line__ "__file__"'
> (also defining the lead-in per file) to add line-continuation awareness and 
> maybe even comment awareness ?
> Or a function
> syncline(`#line '__line__ "__file__")
> to enable switching on/off/changing the syntax?
> Do you accept up-streaming contributions? -> next deadline/release?

Contributions are okay if you are willing to assign copyright to the FSF; 
however, I must be fair and warn you that a contribution to teach
m4 how to report dependency tracking more like gcc has now stalled for several 
years, because there has been very little active development on m4.

Adding new macros must be done carefully (we don't want to break existing use 
of m4 where the new macro name had other purposes).
Also, POSIX is fairly vague at what synclines do, stating only:

> The following options shall be supported:
>
> -s
>     Enable line synchronization output for the c99 preprocessor phase (that 
> is, #line directives).
[https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F9699919799%2Futilities%2Fm4.html&amp;data=04%7C01%7C%7C23490762951141be962d08d92058e703%7Ce764c36b012e4216910d8fd16283182d%7C0%7C0%7C637576389818831668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Mvh9xKIyinIMlrOEC7mXhz2K2EGGQJuc6AbMfJXVl40%3D&amp;reserved=0]

with no mention of what format those lines must take (either on the description 
for m4, or for c99).  But changing their output is also a risk if it is not 
done as an opt-in manner, so figuring out how to opt-in (or even if opting in 
is possible for a given build of m4) needs to be thought about.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org