[PATCH 2/2] Remove dwarf2_cu::language

[Tom Tromey]

Simon> It's not totally clear to me why it's better to go this route, eliminate
Simon> dwarf2_cu::language and keep dwarf2_per_cu_data::lang.  Because I find
Simon> it a bit hard to follow that a dwarf2_per_cu_data is initialized by a
Simon> dwarf2_cu being constructed.

I didn't give it much thought TBH - I was using dwarf2_per_cu_data::lang
in my series, and I assumed that this was there for some other important
reason.  However, I see that this member was added in commit 589902954d
("[gdb] Skip imports of c++ CUs"), and from what I can tell, it should
be fine to switch that code to using dwarf2_cu::language instead.

Simon> So here, instead of referring to per_cu->lang, we could perhaps look up
Simon> to see if a dwarf2_cu exists for `per_cu`, and lookup the language
Simon> there?  The downside would be if a dwarf2_cu has existed but was then
Simon> freed, then we won't see the language.  Whereas by storing the language
Simon> in dwarf2_per_cu_data::lang, it will persist even if the dwarf2_cu gets
Simon> freed.

Yeah, I arrived at this same conclusion...

But actually, I wonder whether that code even needs a language check.
My thought is that an import of a DW_UT_compile / DW_TAG_compile_unit CU
can always be skipped on the grounds that the CU is being scanned
separately anyway.

Tom