[Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Pavel Labath via lldb-commits]

On 22/01/2021 18:42, Jim Ingham wrote:
> If you are just loading an object file and the looking at the line table or something like that, would a UnitTest be more suitable?
> 
> Jim
> 

It depends on who you're talking to. :) I, for one, think we should be 
writing more unit tests, however, this is not a universally accepted 
position (quite the opposite -- some folks will go to enormous lengths 
to avoid writing one -- creating single-purpose utilities, etc.).

A major stumbling block for writing unit tests is the ability to 
generate test inputs (and this is both a consequence of and the source 
of the aversion to unit tests). We now have the ability to generate 
binaries from yaml programatically, but for a long time, we didn't have 
even that (and our unit tests were shelling out to the yaml2obj binary), 
but there's nothing similar for other llvm tools. All of the relevant 
code is already present in llvm, so it wouldn't be impossible to create 
something like that, but it is work...

But even I have to admit that the "lit" style tests have their 
advantages, if used reasonably (no proliferation of one-shot utilities 
and flags, etc.). The tricky thing about unit tests is ensuring they 
produce good (actionable) error messages when that fails. That usually 
means writing to_string methods for all objects being compared. If those 
to_string methods are good, then there shouldn't be much difference 
between comparing their outputs vs. comparing the objects themselves. 
And this is pretty much what FileCheck does. Plus, this has some other 
advantages, like being able to run the tool on random inputs to check 
its output, not needing to recompile when you modify the input, etc.

pl