Re: ObjC patch: fix CLASS_HAS_EXCEPTION_ATTR

["Nicola Pero" <nicola dot pero at meta-innovation dot com>]

> when there is next some time, I was planning to:
> 
> (a) move all the meta-data tests to the torture section (since they  
> verify code-gen)
> (b) this seems a weak area of testing for the GNU runtime, so add to/ 
> strengthen testing there.
> (c) perhaps segregate these particular tests by runtime (these should  
> be the only tests that require that).

Sounds good.  A few comments:

 (a) I agree that we want to run the meta-data tests with the maximum amount
of optimizations to be sure that nothing is optimized away in the metadata
structures; I wonder if we need to test the full list of intermediate optimization
levels [full torture tests take *ages* to run ;-)].  Ideally, everything should
be run under torture (after all, the more you test the better); in practice the
testsuite would take so much longer if we did, and I'm not sure it'd help that
much.  Maybe for meta-data tests we can limit ourselves to a run with no optimizations,
and a run with the maximum amount of optimizations ?  Is that a reasonable
compromise ? :-)

 (b) the GNU runtime tests metadata generation mostly with execution tests.
We now have tests for execution of all of the functions in the "modern" GNU runtime API.
These implicitly test metadata generation: eg, getting the list of protocols from
the runtime won't work unless the compiler has put that list there in the right
format that the runtime can read and work on.

 (c) testing meta-data generation as in (b) is quite a good way to test it across
runtimes.  The API now being almost identical, we can use the same test on all runtimes.
The smaller API differences (eg, with older versions of Darwin) can be managed with #ifdefs.

 (d) of course, writing tests for meta-data generation as in (b) is harder/less immediate,
because you have to figure out how an error in the meta-data generation would affect "end users"
and then write a piece of ObjC code that wouldn't work due to that bug, and that is your
testcase.  Eg, in the case of attribute((objc_exception)), this seems to set a RO_EXCEPTION
flag for the class in the Apple runtime.  Someone would have to figure out how/when that
flag is used to write a testcase that fails when the flag is incorrectly set.  It's obviously
much easier to just write a test that uses scan-assembler to look for the flag in the compiler
output.  (on the other hand, figuring out when that flag is used, and writing a testcase for it,
would mean we can then try that testcase with the GNU runtime and see if we have a bug/missing
feature/compatibility problem in there, so it may still be worth it!). ;-)

Summarizing, I don't mind scan-assembler meta-data generation tests being added (great!), but
I personally would rather write ObjC execution tests that can be more trivially used with different
runtimes and platforms :-)

Thanks