Re: [PATCH] Postpone __LINE__ evaluation to the end of #line directives

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 27 Nov 2013, Max Woodbury wrote:

> On 11/27/2013 05:46 AM, Marek Polacek wrote:> On Wed, Nov 27, 2013 at
> 05:29:22AM -0500, mtewoodbury@gmail.com wrote:
> >> From: Max TenEyck Woodbury <max+git@mtew.isa-geek.net>
> >
> > This patch is badly missing a description.  You also want to mention
> > the PR number, if this fixes a bug.  I guess this is to fix PR58687.
> >
> 
> I am new to GNU patching.  There is some description on Bugzilla.  At
> least one other group I have worked with disliked bug number references
> in patches.

It's best for the gcc-patches submission to be self-contained, with the 
explanation of the issue, why it's a bug, the approach taken to fix it and 
the rationale for that approach.

> Please point me to the formatting requirements for change log entries...

Looking at existing examples in the ChangeLog files is the simplest way of 
getting the hang of them, but

http://gcc.gnu.org/codingconventions.html#ChangeLogs

points to the GNU Coding Standards which give the detailed specification 
at:

http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs

> On 11/27/2013 11:21 AM, Joseph S. Myers wrote:
> > On Wed, 27 Nov 2013, mtewoodbury@gmail.com wrote:
> > 
> > > Copyright 2013 assigned to the Free Software Foundation.
> > 
> > FWIW I don't see this in copyright.list yet.  If you sent the paperwork
> > (whether paper mail or scans) to the FSF over a week ago and haven't had
> > it acknowledged, please chase up assign@gnu.org, and keep chasing them up
> > weekly until it's acknowledged and a maintainer confirms it's now listed
> > in copyright.list.
> 
> I am a new at GNU patching.  I had hoped that a simple assignment in
> the document would be sufficient.  I really do not want to turn
> Everything I do over to FSF...

You can assign copyright in just an individual patch, or all past and 
future changes to an individual GNU project, but in either case there's 
still paperwork involved (which can be done electronically in some cases).

http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.changes

(for assigning changes already done)

http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future

(for assigning past and future changes)

> > > diff --git a/gcc/testsuite/gcc.dg/cpp/line4.c
> > > b/gcc/testsuite/gcc.dg/cpp/line4.c
> > 
> > I think it's best to leave this test as-is and add a new test line9.c
> > specifically for this case of "#line __LINE__".  Changing existing tests
> > unnecessarily complicates establishing whether a newly seen failure is a
> > regression or not.
> 
> HMM?  Not sure I understand that line of reasoning.  The test is about
> setting the line number.  This just adds the __LINE__ special case.

There are eight different lineN.c tests for different aspects of setting 
the line number.  This is a new aspect not previously considered.

It's best that a given test, such as gcc.dg/cpp/line4.c, always stays 
testing the same things, and that new things are tested in new tests.  If 
someone sees line4.c failing and searches for information about that test, 
it's least confusing if any past information about that test and its 
failures is still relevant to the test as it is today - if the test has 
only changed, since it was added, as actually required to reflect 
deliberate changes to what should be expected, and not simply to test new 
things not previously covered by the testsuite at all.

> The other is to postpone macro expansion until the end of the directive
> has been seen.  That would require two passes over the token sequence;
> one to build the sequence and a second to evaluate it.  Doing that is
> 'the right thing' in my opinion but it should be applied to all the
> other directives that permit <pp-token> substitution as well.  I tried
> to do it that way initially, but that requires a deeper understanding
> of the current implementation than I was able to build quickly.  I
> would like to see a 'theory of operation' document that contained such
> details, as some commercial software shops require, but that does not
> seem to be how it is done here.

There's cppinternals.texi, though it may be out of date.

-- 
Joseph S. Myers
joseph@codesourcery.com