Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OCMock 3.8 does not compile in Xcode 11 #472

Closed
madsolar8582 opened this issue Dec 29, 2020 · 3 comments
Closed

OCMock 3.8 does not compile in Xcode 11 #472

madsolar8582 opened this issue Dec 29, 2020 · 3 comments
Labels

Comments

@madsolar8582
Copy link
Contributor

Introduced in ee79b16, OCMock 3.8 does not compile anymore in Xcode 11 as the code being used is only available in Xcode 12 or newer. This was not called out in the release notes nor was a major revision made, so I would consider this non-passive. This can be resolved by placing the code in compile checks, or if this is intended, this should be reverted and 3.8.1 released to restore compatibility with Xcode 11 and then the change remade and re-released as OCMock 4.0.

#if !TARGET_OS_WATCH
if((testCase != nil) && [testCase respondsToSelector:@selector(recordIssue:)])
{
XCTSourceCodeLocation *xctloc = [[[XCTSourceCodeLocation alloc] initWithFilePath:[loc file] lineNumber:[loc line]] autorelease];
XCTSourceCodeContext *xctctx = [[[XCTSourceCodeContext alloc] initWithLocation:xctloc] autorelease];
XCTIssue *issue = [[[XCTIssue alloc] initWithType:XCTIssueTypeAssertionFailure compactDescription:description
detailedDescription:nil sourceCodeContext:xctctx associatedError:nil attachments:[NSArray array]] autorelease];
[testCase recordIssue:issue];
}
else
#endif

@erikdoe
Copy link
Owner

erikdoe commented Dec 30, 2020

Apologies, it looks like I missed the availability note in the documentation. It's curious, though, because I could have sworn that the deprecation warning for the older API appeared before Xcode 12, so I didn't expect that the replacement would require Xcode 12. Well, that teaches me to respond to Apple's deprecating warnings in a timely manner.

(Minor rant: of course I'm aware of Apple's tendency to push for the latest and greatest quite aggressively, but I also feel this is getting worse these days. The other day I tried to use a new feature of Swift UI and it suddenly required Big Sur as a minimum deployment target...)

Do you happen to know how to do compile time checks for the Xcode version? If that's not possible, I guess, I could always look up the classes by their name.

@erikdoe erikdoe added the bug label Dec 30, 2020
@madsolar8582
Copy link
Contributor Author

madsolar8582 commented Dec 30, 2020

No worries Erik. If we're talking about Apple being Apple we can also rant about their missing documentation 🙃.

To fix this, you can pull in the Availability header (<Availability.h>) and use the __IPHONE_X_Y definition (or macOS/tvOS; your choice) in an #ifdef. So if we need to check for Xcode 12+, that would look something like:

#ifdef __IPHONE_14_0
if (newThing) {
  // Do new thing
}
else {
  // Do old thing
}
#else
 // Do old thing
#endif

It unfortunately leads to a bit of code duplication, but it makes things backwards compatible. Luckily XCTest is shipped in Xcode itself and not the SDKs, otherwise you'd have to wrap things in the @available check too.

@erikdoe
Copy link
Owner

erikdoe commented Dec 30, 2020

I think I fixed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants