That seems reasonable. I'll work that in. -Todd
> On Dec 3, 2015, at 4:55 PM, Zachary Turner <ztur...@google.com> wrote: > > It would also be nice if the summary statistics were printed after the list > of failing / errored tests. The reason is that it involves a fixed number of > lines to print the table, but the list of failures and errors is a variable > number of lines which could potentially be very long and push the statistics > off the screen. > >> On Thu, Dec 3, 2015 at 10:08 AM Zachary Turner <ztur...@google.com> wrote: >> Ahh I read further and see this was already mentioned by Pavel. >> >>> On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner <ztur...@google.com> wrote: >>>> On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala <todd.fi...@gmail.com> wrote: >>>>> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner <ztur...@google.com> wrote: >>>>> >>>>> >>>>>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala <todd.fi...@gmail.com> wrote: >>>>>> >>>>>>> and the classname could be dropped (there's only one class per file >>>>>>> anyway, so the classname is just wasted space) >>>>>> >>>>>> Part of the reason I included that is I've hit several times where copy >>>>>> and paste errors lead to the same class name, method name or even file >>>>>> name being used for a test. I think, though, that most of those are >>>>>> addressed by having the path (relative is fine) to the python test file. >>>>>> I think we can probably get by with classname.methodname (relative test >>>>>> path). (From your other email, I think you nuke the classname and keep >>>>>> the module name, but I'd probably do the reverse, keeping the class name >>>>>> and getting rid of the module name since it can be derived from the >>>>>> filename). >>>>> >>>>> I don't think the filename can be the same anymore, as things will break >>>>> if two filenames are the same. >>>> >>>> Maybe, but that wasn't my experience as of fairly recently. When tracking >>>> failures sometime within the last month, I tracked something down in a >>>> downstream branch with two same-named files that (with the legacy output) >>>> made it hard to track down what was actually failing given the limited >>>> info of the legacy test summary output. Maybe that has changed since >>>> then, but I'm not aware of anything that would have prohibited that. >>> >>> Well I only said "things" will break, not everything will break. Most >>> likely you just didn't notice the problem or it didn't present itself in >>> your scenario. There are definitely bugs surrounding multiple files with >>> the same name, because of some places where we use a dictionary keyed on >>> filename. >>>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
