Added tests for NSHashTable/NSMapTable weak objects support

[triplef]

I wrote these tests in order to track down the issues we’re seeing with weak pointer support in NSHashTable and NSMapTable that I outlined on the mailing list:
https://lists.gnu.org/archive/html/discuss-gnustep/2019-10/msg00008.html

The tests pass when run against Apple’s Foundation, but are failing for me when run on Android. I’d like to understand whether other configurations are affected as well (e.g. the CI test builds).

If they are failing on the CI I’d appreciate any fixes or insights into why that is the case. If they pass, please feel free to merge – we will then know to look for the issue in our toolchain configuration.

[triplef]

Looks like these issues are not specific to our setup. Any thoughts on why these tests might be failing? Unfortunately I don’t have a way to fully debug the issues on Android...

[triplef]

Looks like #84 will be fixing these tests. I will rebase once it’s merged.

[ngrewe]

Ah, this branch still fails with the gcc runtime, where NSPointerFunctionsWeakMemory behaves the same as NSPointerFunctionsZeroingWeakMemory, so the failure is rather unsurprising (we don't have GC enabled, so we end up with non-retained objects in the hash table). I think we should SKIP these tests – and maybe don't even define NSPointerFunctionsWeakMemory unless we are building base with an ARC-enabled runtime.

[triplef]

Good catch, thanks. I tried using OBJC_CAP_ARC to skip the tests with GCC, but it looks like the define is also not available with Clang/NG (even though it’s already being used in the NSProxy/basic test). Is there another define I could use here?

[ngrewe]

I tried using OBJC_CAP_ARC to skip the tests

You'll need to include <objc/capabilities.h> in order to get that macro. It's also just a constant describing the runtime capability and doesn't tell you whether the runtime was compiled with support for that capability (though in case of ARC, that should always be the case). To know whether the runtime actually supports it, you need to use it in conjunction with objc_test_capability() (the NSProxy/basic.m test gets that wrong).

[triplef]

Thanks @ngrewe! I’ve updated the tests to include capabilities.h and use objc_test_capability(), and the tests are now correctly skipped with GCC and pass with Clang. ✅

Looking at the NSProxy/basic test I think in that case the check might be correct, as it’s mirroring the same kind of checks in NSObject.m. It was all introduced as part of commit e35eb61.

[ngrewe]

Looking at the NSProxy/basic test I think in that case the check might be correct, as it’s mirroring the same kind of checks in NSObject.m

Yeah, that's probably functionally okay, since you can't compile libobjc2 without ARC support, it might just set a bit of a bad precedent for people looking at how to use the capabilities interface in libobjc2.