Major debugging breakage

[law@redhat.com]

  > Possibly.  One obvious idea I had that I never investigated was that
  > something was using the line number from the start or end of the
  > expressions only.  This could be a parser problem, or a problem with a
  > variable being clobbered, or a whole host of things.  The last big
  > line number complaint and bug fix was just before 3.0, which was
  > resolved by Mark finding a bug in the C++ front end.  I suspect that
  > whatever is causing this is quite trivial (if hard to find).
Well, from my reading I think the core problem is we're trying to use the
diagnostic line #s (ie SRC_LINENO) for debugging purposes or we're not
storing away the line number for the statement early enough.

To restore previous behavior we need to use the line number for the start
of the statement for debugging purposes.  Long term we'd probably want a
new line number for each line in each statement, but that would be an
enhancement :-)

  > I don't like the way that lineno is kind of global, and everything
  > seems to read (and in one or two places write to) it willy-nilly.
Agreed.  This is rather disgusting.

  > It's always struck me as wrong-headed that the debug routines should
  > reference it directly at all.
Yes.


  > But I'm pretty much lost when it comes
  > to debug info.  I can find my way round the C tree front end without
  > too much difficulty, but I've never delved into RTL seriously.
You don't really need to get into the guts of RTL to observe this problem;
it's easily observable at tree->rtl conversion time.


  > Yup; that's my work from 3.1; 3.0 was different (I'm responsible for
  > half the comments around cb_file_change, too).  I don't think there's
  > an issue there.  I think the lineno code is generally correct, because
  > the C / ObjC / C++ front-end diagnostics always come out at the right
  > place (modulo the occasional parser issue with needing to e.g. find a
  > brace for context).  It seems that line numbers are not being
  > correctly assigned to (sub-)expressions somewhere.
I don't necessarily think there's an issue here either.  It makes perfect
sense to have the line number change at each non-empty line for diagnostic
purposes (and one day for debugging purposes).


  > The reason I mentioned cb_file_change at all is because there is no
  > real documentation of what the debug code expects lineno to be set to
  > at any particular time; so I'm not sure that e.g. the debug callbacks
  > in cb_file_change are happening at the right time w.r.t. updating
  > lineno.  Just an idea.
Yea.  Basically we have a mess of spaghetti code that probably nobody
really understands and which isn't documented.  Ugh.

jeff