[RFA,04/42] Move last_source file to buildsym_compunit

  This moves the global last_source_file into buildsym_compunit.

gdb/ChangeLog
2018-05-22  Tom Tromey  <tom@tromey.com>

	* buildsym.c (buildsym_compunit::buildsym_compunit): Add name
	parameter.
	(buildsym_compunit::set_last_source_file): New method.
	<m_last_source_file>: New member.
	(prepare_for_building): Remove "name" parameter.
	(start_symtab, restart_symtab, reset_symtab_globals): Update.
	(last_source_file): Remove.
	(set_last_source_file, get_last_source_file): Update.
---
 gdb/ChangeLog  | 11 +++++++++++
 gdb/buildsym.c | 44 ++++++++++++++++++++++++++------------------
 2 files changed, 37 insertions(+), 18 deletions(-)
  

On 2018-05-23 12:58 AM, Tom Tromey wrote:
> @@ -140,6 +147,12 @@ struct buildsym_compunit
>    /* The subfile of the main source file.  */
>    struct subfile *main_subfile = nullptr;
>  
> +  /* Name of source file whose symbol data we are now processing.  This
> +     comes from a symbol of type N_SO for stabs.  For Dwarf it comes

I think it's spelled DWARF (all caps)?

> +     from the DW_AT_name attribute of a DW_TAG_compile_unit DIE.  */
> +
> +  gdb::unique_xmalloc_ptr<char> m_last_source_file;

Nit: remove the empty line between the comment and the field.

Should this new field be private?

Otherwise, LGTM.

Simon
  

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> On 2018-05-23 12:58 AM, Tom Tromey wrote:
>> @@ -140,6 +147,12 @@ struct buildsym_compunit
>> /* The subfile of the main source file.  */
>> struct subfile *main_subfile = nullptr;
>> 
>> +  /* Name of source file whose symbol data we are now processing.  This
>> +     comes from a symbol of type N_SO for stabs.  For Dwarf it comes

Simon> I think it's spelled DWARF (all caps)?

Yeah, I just moved the old comment; but I've updated it now.

>> +     from the DW_AT_name attribute of a DW_TAG_compile_unit DIE.  */
>> +
>> +  gdb::unique_xmalloc_ptr<char> m_last_source_file;

Simon> Nit: remove the empty line between the comment and the field.

Done.

Simon> Should this new field be private?

All the data members are private by the end of the series, but I didn't
generally try to do that at each step along the way.  This is one of
those compromises I mentioned in the cover letter -- where a bigger
reordering of the series might have yielded a prettier series, but
didn't seem worth the effort.

Tom
  

On 2018-07-08 12:33 PM, Tom Tromey wrote:
> All the data members are private by the end of the series, but I didn't
> generally try to do that at each step along the way.  This is one of
> those compromises I mentioned in the cover letter -- where a bigger
> reordering of the series might have yielded a prettier series, but
> didn't seem worth the effort.

Ok, no problem then.  You can ignore other similar comments I've already sent.

Simon
  

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

Simon> On 2018-07-08 12:33 PM, Tom Tromey wrote:
>> All the data members are private by the end of the series, but I didn't
>> generally try to do that at each step along the way.  This is one of
>> those compromises I mentioned in the cover letter -- where a bigger
>> reordering of the series might have yielded a prettier series, but
>> didn't seem worth the effort.

Simon> Ok, no problem then.  You can ignore other similar comments I've
Simon> already sent.

I already sent one other reply but you can likewise ignore that :)

This series is a bit unwieldy.  And I should probably have mentioned
earlier (before Keith went to the effort of applying it...) that it is
in my github as submit/buildsym-fixups, in case you wanted to check it
out or something.

Tom
  

On 2018-07-08 12:52 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
> Simon> On 2018-07-08 12:33 PM, Tom Tromey wrote:
>>> All the data members are private by the end of the series, but I didn't
>>> generally try to do that at each step along the way.  This is one of
>>> those compromises I mentioned in the cover letter -- where a bigger
>>> reordering of the series might have yielded a prettier series, but
>>> didn't seem worth the effort.
> 
> Simon> Ok, no problem then.  You can ignore other similar comments I've
> Simon> already sent.
> 
> I already sent one other reply but you can likewise ignore that :)
> 
> This series is a bit unwieldy.  And I should probably have mentioned
> earlier (before Keith went to the effort of applying it...) that it is
> in my github as submit/buildsym-fixups, in case you wanted to check it
> out or something.

It's been mostly fine so far (just one or two trivial merge conflicts), but
thanks for tip anyway.  The patches are good on their own I think, so feel free
to start pushing them as soon as they are approved, so the pendant part of the
series gradually shrinks.

Simon