Have a non-ARC app. The unit test target is the standard XCTest framework created from XCode and that target is ARC itself, meaning in the unit tests use ARC but all the actual app's code is non-ARC. Everything fine with this setup. Until...
Introduced a new class instance method in the app like this:
- (NSArray *)newThingy
{
NSArray *arr = [[NSArray new] autorelease];
// some logic here
return arr;
}
Created a unit test for it like this:
MyClass *class1 = [MyClass new];
NSArray *req = [class1 newThingy]; // returns a new object
XCTAssertEqualObjects(myarr[@"somethingtocheck"], @"somevalue");
The unit test itself throws an exception for releasing an object after its already been released. After realizing I have other classes doing pretty much the same thing perfectly fine even in tests, I tracked it down to this line in the new method:
NSArray *arr = [[NSArray new] autorelease];
Removing the autorelease alleviates the exception, but AFAIK that's normal compliant non-ARC logic conforming to the release/retain cycle rules and causes no issues in the app itself. plus again, doing that same sort of thing perfectly fine in other methods in the app. After researching and trying things I found out that what's causing the exception is the method itself being named newXXXX where XXXX is any camel-cased name, i.e. starting with an upper case letter after 'new'. So naming the method 'newThingy' causes an exception, so does 'newSomeOtherThingy', but 'newthingy' (note all lowercase) makes the exception disappear!
Is this some LLVM compiler quirk that we are supposed to be aware of? It reminds me of a static lib I use where that framework has a method named 'copyData' and the LLVM static analyzer complains about it even though there's no issues with the code, likely because it's keying off the 'copy' keyword and thinking it's the NSCopying protocol copy method when in fact it's not. I've learned my lesson to not name method with newSomethingHere, but want to make sure there's not some dev doc I've missed along the way. Seems like LLVM doesn't like methods named newSomthingCamelCase, at least not when mixing ARC/non-ARC?
