-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Refactor FXIOS-12796 [Swift 6 Migration] Fix more under-specified protocols #29650
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
Refactor FXIOS-12796 [Swift 6 Migration] Fix more under-specified protocols #29650
Conversation
…bView, InsetUpdatable, PhotonActionSheetContainerCellDelegate, NavigationController.
yoanarios
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM I just have a quick question
| import Shared | ||
| import ComponentLibrary | ||
|
|
||
| @MainActor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a quick question: how should we decide when to annotate an entire protocol with @mainactor versus adding it only to individual methods or conforming types (like in AddressToolbarDelegate above)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I usually think of it like this: if it is a protocol that will only ever apply to a UI class, then it's worth annotating the entire protocol as a shorthand (in this case it's for a tab view). This is because Apple has @MainActor isolation already on all its UI code.
But if it's a delegate protocol where it's possible that a non-UI class (which would therefore not have main actor isolation) might implement it, I only mark the methods and properties inside the protocol individually. This is less restrictive, as it tells the compiler the entire type is not required to be @MainActor.
I have a playground demo and more detailed explanation pinned here in slack!
| import Foundation | ||
| import UIKit | ||
|
|
||
| public protocol AddressToolbarDelegate: AnyObject { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding below comment, I would think toolbar relates to UI and that whole protocol should be @MainActor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The toolbar is UI, but a delegate could theoretically be a service or manager class that doesn't need to be entirely main actor, or maybe even shouldn't be main actor isolated if it's doing async work. 👀
In this case though I agree it's very likely going to be a UI subclass that conforms to it (in fact a UIView class is the conforming class in our code). That said, I thought I'd put in a little extra effort to be less restrictive just in case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super familiar with this area of the code so if it's really obvious this should be only UI classes conforming to this protocol, then it would be totally reasonable to @MainActor the whole thing!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can ask @thatswinnie opinion on it 👀 Not a blocker thought for this PR
💪 Quality guardian1 tests files modified. You're a champion of test coverage! 🚀 🌱 Tiny but mightyOnly 29 line(s) changed. Fast to review, faster to land! 🚀 🙌 Friday high-fiveThanks for pushing us across the finish line this week! 🙌 💬 Description craftsmanGreat PR description! Reviewers salute you 🫡 Client.app: Coverage: 37.35
ToolbarKit: Coverage: 63.15
Generated by 🚫 Danger Swift against 6afc5a3 |
… from last week (#5) (#29657) * Refactor FXIOS-13511 [Swift 6] Remove Equatable from AppState and other redux states (#29495) * Remove unneeded equatable conformance on redux states * Fix tests * Fix test * Refactor FXIOS-13532 [Swift 6 Migration] Fix strict concurrency errors related to Notifications (#29514) Fun stuff * Refactor FXIOS-13502 [Swift 6 Migration] Fix main actor isolation warnings in MozillaRustComponents (#29426) "Fix" main actor isolation warnings in MozillaRustComponents with a workaround for setting accessibility identifiers to prevent larger impacts and errors in Client generated code. * Refactor FXIOS-13511 [Swift 6] Move Tab to MainActor and resolve strict concurrency warnings (#29497) * Refactor FXIOS-13511 [Swift 6] Remove Equatable from AppState and other redux states (#29495) * Remove unneeded equatable conformance on redux states * Fix tests * Fix test * Refactor FXIOS-13532 [Swift 6 Migration] Fix strict concurrency errors related to Notifications (#29514) Fun stuff * first pass of isolating tab to the main actor * Clean up tests and push commented out code * fix additional warnings * Clean up remaining warnings * fix tests * add missing ticket numbers * resolve introduced warning --------- Co-authored-by: lmarceau <lmarceau@mozilla.com> * Refactor FXIOS-13532 #29411 [Swift 6 Migration] AppDelegate + PushNotification (#29590) * Fix for Constellation update * Fix UNUserNotificationCenterDelegate methods * Fix tests * Refactor FXIOS-13235 [Swift 6 Migration] Enable strict concurrency checking in SummarizerKit (#29575) * Enable strict concurrency in SummarizerKit. * Fix closure `Sendable` warnings. * Fix some other warnings. Suppress others with FIXME tickets. * Refactor FXIOS-13463 #29256 [Swift 6 Migration] WebEngine @mainactor (#29393) * Policy decider * Make main actor * @mainactor stuff * Fix the tests * Adjust Client * Add ticket number * Adjust following comments * Refactor FXIOS-12796 [Swift 6 Migration] Fix more under-specified protocols (#29650) * Fix under-specified protocols: AddressToolbarDelegate, EmptyPrivateTabView, InsetUpdatable, PhotonActionSheetContainerCellDelegate, NavigationController. * Fix unit tests. * Refactor FXIOS-13502 [Swift 6 Migration] Fix or suppress `Sendable` and misc. warnings in MozillaRustComponents (round 1) (#29425) * Fix or suppress Sendable warnings in MozillaRustComponents. * Janky workaround for main actor isolation warning. * Update some Rust Components Sendable callbacks with @mainactor as well so the Client can reason better about main actor isolation. * Refactor FXIOS-13511 [Swift 6] Additional Strict Concurrency Clean up for Tab and Friends (#29628) * Additional tab clean up * Isolate UserScriptManager to main actor * fix tests * turn off strict concurrency * more main actor isolation * resolve introduced warnings --------- Co-authored-by: Carson Ramsden <carsonramsden@gmail.com> Co-authored-by: lmarceau <lmarceau@mozilla.com>
📜 Tickets
Jira ticket
Github issue
💡 Description
Fix under-specified protocols by adding isolation details: AddressToolbarDelegate, EmptyPrivateTabView, InsetUpdatable, PhotonActionSheetContainerCellDelegate, NavigationController.
cc @Cramsden @lmarceau @dataports | Swift 6 Migration
📝 Checklist