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

Use Xcode 15.0.1 #1377

Merged
merged 13 commits into from
Apr 16, 2024
Merged

Use Xcode 15.0.1 #1377

merged 13 commits into from
Apr 16, 2024

Conversation

jkmassel
Copy link
Contributor

@jkmassel jkmassel commented Nov 4, 2023

Migrates the project to Xcode 15 and Apple Silicon in CI

Also includes:

  • An adjustment to the UITextView subclass that injects a UIPasteboard object. This allows us to mock access to the system pasteboard, which requires user interaction in recent iOS versions
  • An adjustment to string index handling – in newer versions of Xcode, there are runtime assertions about string index overflow, so we need to be a bit more careful when replacing text
  • A tiny little fix for a failing test, presumably related to something about how iOS generates PNG files.

This can be reviewed by anyone, but I'd appreciate if @mokagio or @crazytonyli took a look at the project code adjustments!

Testing Details

Ensure CI passes


  • Please check here if your pull request includes additional test coverage.
  • I have considered if this change warrants release notes and have added them to the appropriate section in the CHANGELOG.md if necessary.

This resolves a string overflow issue that appeared in tests in Xcode 15.0.1
Apple requires user interaction to allow using the pasteboard – this change allows us to mock the pasteboard while under test to avoid that
@jkmassel jkmassel requested a review from a team November 4, 2023 02:26
@jkmassel jkmassel self-assigned this Nov 4, 2023

func isValidIndex(_ index: String.UTF16View.Index) -> Bool {
(self.startIndex ... self.endIndex).contains(index)
}
Copy link
Contributor

@crazytonyli crazytonyli Nov 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The endIndex is not an accessible index.

A string’s “past the end” position—that is, the position one greater than the last valid subscript argument.

}

func isValidIndex(_ index: String.UTF16View.Index) -> Bool {
(self.startIndex ... self.endIndex).contains(index)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(self.startIndex ... self.endIndex).contains(index)
(self.startIndex ..< self.endIndex).contains(index)

# post a message in the logs
cat .buildkite/validate_podspec_annotation.md
# and also as an annotation
cat .buildkite/validate_podspec_annotation.md | buildkite-agent annotate --style 'warning'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a new workaround for this issue: You can pass a --patch-cocoapods option to validate_podspec and the publish pod utilities. See https://github.com/wordpress-mobile/WordPressKit-iOS/pull/652/files.

Copy link
Contributor

@crazytonyli crazytonyli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe updating the publishing pod commands in.buildkite/publish-aztec-pod.sh too, with the same --patch-cocoapods option? Otherwise, future releasing jobs would fail.

env: *common_env
plugins: *common_plugins
agents:
queue: upload
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This agents configuration needs to be removed.

@@ -495,7 +495,7 @@ open class TextView: UITextView {
// MARK: - Intercept copy paste operations

open override func cut(_ sender: Any?) {
let data = storage.attributedSubstring(from: selectedRange).archivedData()
let data = try! storage.attributedSubstring(from: selectedRange).archivedData()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does that mean this line crashes if the selected attributed string contains an "attribute value" that doesn't conform to NSCoding? I don't really know anything about this library's implementation, not sure how likely that's going to happen...

Copy link
Contributor

@AliSoftware AliSoftware Dec 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good question, but also before the migration to Xcode 15 and newer Swift back when archivedData was not marked as throws, I'd expect the code would already crash (but maybe with an ObjC NSException rather than a Swift error being thrown)?

That being said, it would be a nice improvement to use let data = try? … instead and then make the subsequent call to storeInPasteboard(encoded: data) conditional on if let data; but not sure if that fix belongs in this PR or separate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, looking at the deprecated vs new method signature for NSKeyedArchiver.archivedData, I'm wondering if the only case where it could throw is if you passed requiresSecureCoding: true and the objects conformed to NSCoding… but not NSSecureCoding.

But since here we use requiresSecureCoding: false in the implementation of archivedData, maybe that means we'll never throw in practice? Or if we do, that would be under the same conditions as the ones the current version of the library already does, i.e. not related to Xcode 13->Xcode15 migration?

@AliSoftware
Copy link
Contributor

AliSoftware commented Dec 20, 2023

Breadcrumbs: I reverted the attribution of the cluster to this repo in Buildkite (https://github.com/Automattic/buildkite-ci/pull/331) — aka reverted this repo to use Intel infra — while this PR is still not merged.

Once we land this PR, don't forget to redo the change in aztec-editor-ios.tf to switch it back to use the cluster again.

@mokagio
Copy link
Contributor

mokagio commented Jan 12, 2024

I wanted to help here and tried to address the unit tests failures via #1382 but didn't get very far.

@mokagio
Copy link
Contributor

mokagio commented Apr 16, 2024

Going to merge this despite unit tests failures, to unblock moving to the cluster in CI, which in turns unblocks adopting the latest Xcode, #1392, which, finally, will unblock #1391.

I'm still experiencing unit tests issue locally, but I want to see how/if the situation changes once this lands.

@mokagio mokagio disabled auto-merge April 16, 2024 04:56
@mokagio mokagio merged commit 0fd30b2 into develop Apr 16, 2024
4 of 6 checks passed
@mokagio mokagio deleted the use/xcode-15.0.1 branch April 16, 2024 04:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants