-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Clean up _BridgedNSError and _BridgedStoredNSError #14682
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
Clean up _BridgedNSError and _BridgedStoredNSError #14682
Conversation
Despite their similar names and uses, these protocols no longer share much functionality - the former is used to take @objc enums defined in Swift that conform to Error and expose them as NSErrors, and the latter handles NS_ERROR_ENUM C enums, which get imported into Swift as a wrapper around NSError. We can actually simplify them quite a bit. - Eliminate base protocol __BridgedNSError, which no longer provides any implementation for _BridgedStoredNSError. - Eliminate default implementations that match what the compiler would synthesize. - Adopt recursive constraints and where-clauses on associated types (and update the Clang importer to handle this). - Collapse signed and unsigned default implementations when reasonable. - Fold _BridgedStoredNSError's _nsErrorDomain into the existing public requirement CustomNSError.errorDomain. rdar://problem/35230080
if (auto *depBase = origBase->getAs<DependentMemberType>()) { | ||
Type substBase = recursivelySubstituteBaseType(conformance, depBase); | ||
ModuleDecl *module = conformance->getDeclContext()->getParentModule(); | ||
return depMemTy->substBaseType(module, substBase); |
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.
This definitely needs a check from someone who understands the ramifications better than I do.
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.
This feels like it should be a Type::subst()
, not its own subst-like recursive algorithm.
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.
Oops, I forgot this change was in here, or I wouldn't have merged until you got a chance to review. IIRC we can't use Type::subst
because we're still in the process of building the conformance, but I could be wrong.
/// The error code for the given error. | ||
var code: Code { get } | ||
associatedtype Code: _ErrorCodeProtocol, RawRepresentable | ||
where Code.RawValue: FixedWidthInteger |
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.
This was the last thing I couldn't update. These constraints ought to be on _ErrorCodeProtocol itself, because there'll never be any _ErrorCodeProtocol types that don't match, but the compiler crashes if I try to do that when we actually go to use the conformance. I'll try to come up with a reduced case that doesn't depend on the importer.
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.
Okay, no luck with a reduction, but that's because it's the ClangImporter code I mentioned above that's at fault. Clearly it needs more actual attention and not a quick fix.
@swift-ci Please test |
@swift-ci Please test source compatibility |
@swift-ci Please test compiler performance |
I'm counting that as a success. The numbers barely changed. (Still waiting on review. This isn't urgent.) |
Review ping |
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.
So you are now making errorDomain API? instead of underscored public?
Has this been passed to Cocoa API review?
Ah, it's already API via the CustomNSError protocol. Sorry for not making that clear. |
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.
since it is an existing API the changes look non threatening to me, however truthfully I am not certain of exactly what the difference is here.
It does mean that external clients may end up referencing the entry points directly, which implies that we wouldn't ever be able to remove them, but we wouldn't ever be able to remove them anyway because they're doing something useful. So maintaining that difference in the ABI doesn't seem useful to me. |
Despite their similar names and uses, these protocols no longer share much functionality - the former is used to take
@objc
enums defined in Swift that conform to Error and expose them as NSErrors, and the latter handles NS_ERROR_ENUM C enums, which get imported into Swift as a wrapper around NSError. We can actually simplify them quite a bit.Eliminate base protocol __BridgedNSError, which no longer provides any implementation for _BridgedStoredNSError.
Eliminate default implementations that match what the compiler would synthesize.
Adopt recursive constraints and where-clauses on associated types (and update the Clang importer to handle this).
Collapse signed and unsigned default implementations when reasonable.
Fold _BridgedStoredNSError's _nsErrorDomain into the existing public requirement CustomNSError.errorDomain.
rdar://problem/35230080