Re: More ObjC++ work on @encode in C++ templates

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

>> Sure, I love the idea of using subdirectories.  We could put all the  
>> "old"
>> tests into a "misc" or "old" subdirectory.  So, we reorganize tests  
>> as in
>
> we would, in any case, end up needing a misc dir - since it is  
> inefficient to have only one or two tests in a subdir (all the  
> overhead of a new .exp).

I briefly looked at g++.dg/ and they have a single dg.exp which runs
all the tests in all the subdirectories (with the exceptions of the directories
that run special tests).

So there should be no particular overhead to using subdirectories; even multiple
levels. :-)

So, maybe we could use

 objc.dg/encode/base/... <encode tests shared with the apple/trunk branch>
 objc.dg/encode/...      <new encode tests>

 objc.dg/fast-enumeration/base/... <fast enumeration tests shared with the apple/trunk branch>
 objc.dg/fast-enumeration/...      <new fast enumeration tests>

 objc.dg/{topic}/base/...          <test on {topic} shared with the apple/trunk branch>
 objc.dg/{topic}/...               <new tests on {topic} that we add>

That should take care of your concern that all tests for fast enumeration (for example)
should be in the same place.

It would still be easy to compare our list of tests with the one from llvm-gcc-4.2 (as Mike
wants to be able to), as you would simply do

ls objc.dg/*/base/

to get the list of our tests shared with the apple/trunk branch (you don't even need find), which
you can immediately compare with the list in llvm-gcc-4.2 (and, there won' be any confusing clashes
due to names).

Anyway, let's continue the discussion when you are back online in a few days. :-)

Thanks