Skip to content

Ask Foundation to capture NSError/CFError backtraces for us. #673

New issue

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

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

Already on GitHub? # to your account

Merged
merged 3 commits into from
Sep 9, 2024

Conversation

grynspan
Copy link
Contributor

@grynspan grynspan commented Sep 9, 2024

On Apple platforms, when an error occurs in an Objective-C method or C function, convention is to return the error as an instance of NSError/CFError via an out-parameter. When that Objective-C method or C function is called by a Swift function, the Swift function detects the error, then effectively rethrows it, at which point our swift_willThrow hook is triggered. This can obscure the real origin of the error which may be many stack frames down from the point Swift takes over.

This PR asks Foundation, via a relatively new internal function, to capture backtraces for instances of NSError and CFError at the point they are created. Then, when Swift Testing attempts to look up the backtrace for an error it has caught, if Foundation has generated one, then Swift Testing can substitute it in place of the one it generated in the swift_willThrow hook.

Resolves rdar://114386243.

Checklist:

  • Code and documentation should follow the style of the Style Guide.
  • If public symbols are renamed or modified, DocC references should be updated.

On Apple platforms, when an error occurs in an Objective-C method or C function,
convention is to return the error as an instance of `NSError`/`CFError` via an
out-parameter. When that Objective-C method or C function is called by a Swift
function, the Swift function detects the error, then effectively rethrows it, at
which point our `swift_willThrow` hook is triggered. This can obscure the real
origin of the error which may be many stack frames down from the point Swift
takes over.

This PR asks Foundation, via a relatively new internal function, to capture
backtraces for instances of `NSError` and `CFError` at the point they are
created. Then, when Swift Testing attempts to look up the backtrace for an error
it has caught, if Foundation has generated one, then Swift Testing can
substitute it in place of the one it generated in the `swift_willThrow` hook.

Resolves rdar://114386243.
@grynspan grynspan added enhancement New feature or request tools integration Integration of swift-testing into tools/IDEs darwin 🍎 macOS, iOS, watchOS, tvOS, and visionOS support swift-6.1 labels Sep 9, 2024
@grynspan grynspan self-assigned this Sep 9, 2024
Copy link
Contributor

@stmontgomery stmontgomery left a comment

Choose a reason for hiding this comment

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

Nice!

@grynspan
Copy link
Contributor Author

grynspan commented Sep 9, 2024

@swift-ci test

@grynspan
Copy link
Contributor Author

grynspan commented Sep 9, 2024

@swift-ci test

@grynspan grynspan merged commit f6af3d8 into main Sep 9, 2024
3 checks passed
@grynspan grynspan deleted the jgrynspan/foundation-error-backtraces branch September 9, 2024 16:31
@grynspan grynspan added this to the Swift 6.1 milestone Sep 10, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
darwin 🍎 macOS, iOS, watchOS, tvOS, and visionOS support enhancement New feature or request tools integration Integration of swift-testing into tools/IDEs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants