ObjC/ObjC++: bug fixes for @catch

[Mike Stump]

On Nov 29, 2010, at 12:30 AM, IainS wrote:
> FWIW, for example:  make check-objc RUNTESTFLAGS="strings.exp=* "
> --- will run all the .dg _and_ .dg/torture string tests ... which I think is useful.

Well, except this doesn't work for things that don't have an .exp file...  :-(  The dg.exp=cfstring\*.m method does work, always.

> Of course, one needs to decide on what constitutes a 'major' category.

In general, I'd prefer most testcases to fit in a very small number of framework drivers.  I'm not in favor of just randomly creating new drivers for the sole purpose of providing group naming.  We create them, when the existing drivers can't meet the needs and should not be extended to meet those needs.  This in general means, no major categories, rather, we have specific needs, like, lto, dg, torture.  These aren't categories of testcases, but rather, different sets of specialized needs of test cases.

Now, when to create a new driver or fold it into an existing one.  It must be handled on a case by case basis.  In general, if an existing driver would work, I prefer using it.  Only when that doesn't work, and the feature set needed doesn't fit into the framework, we create a new driver.

> - but I believe having everything in one place is not the way to facilitate easy maintenance.

I don't follow.  dg.exp=eh-*.C for example is isomorphic to dg.exp=eh/*.C, which is isomorphic to eh.exp,  Now, if your only complaint is that eh.exp is a few characters shorter, well, yes, this is true...  What are the 4 most important qualities you're interested in?

> P.S. I guess we need to reach consensus [ or have a ruling :-)  ] since
> (a) we're expanding the test-suite quite fast at the moment
> (b) I was intending to document it before 4.6 goes out

Wait, consensus, I thought we practiced benevolent dictator?  :-)

Now, as a directory balloons out, yes, we tend to split testcases out, so for example, today we might have exception-1.m, and tomorrow it may well be exception/exception-1.m...  We aren't quite there yet.