-
Notifications
You must be signed in to change notification settings - Fork 1.4k
convert the PackageLoading module to the new diagnostics apis #3754
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
Conversation
motivation: adapt new diagnostics apis changes: refactor the PackageLoading module to use new diagnostics api
@swift-ci please smoke test |
// The following rules are documented at https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md#creating-c-language-targets. To avoid breaking existing packages, do not change the semantics here without making any change conditional on the tools version of the package that defines the target. | ||
|
||
let diagnosticsEmitter = observabilityScope.makeDiagnosticsEmitter { |
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.
Is this part about creating a diagnostics emitter temporary until the old diagnostics engine has been removed, or will every client function create its own emitter in the future as well?
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.
in most cases, code would emit directly from the ObservabilityScope
, however, there are cases where you may want to customize metadata further without nesting another scope, which you can do in one of two ways: either create a DiagnosticsEmitter
with additional metadata , or specific the additional metadata on the emit()
call itself. in this case we choose the former since the code emit in many places so its more efficient to hold a emitter with metadata set.
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.
Makes sense. It will be interesting to see how this can be simplified if we have task locals or similar. It seems compelling to want to wrap a closure and add metadata to any diagnostics it emits without quite so much ceremony.
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.
agreed. when we migrate the code to 5.5/5.6 we would be able to take advantage of task locals
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.
Nice! Right, it wasn't so much a commentary on this PR as thinking ahead. This looks good to me.
motivation: adapt new diagnostics apis
changes: refactor the PackageLoading module to use new diagnostics api