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
