Skip to content

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

Merged
merged 1 commit into from
Sep 17, 2021

Conversation

tomerd
Copy link
Contributor

@tomerd tomerd commented Sep 17, 2021

motivation: adapt new diagnostics apis

changes: refactor the PackageLoading module to use new diagnostics api

motivation: adapt new diagnostics apis

changes: refactor the PackageLoading module to use new diagnostics api
@tomerd
Copy link
Contributor Author

tomerd commented Sep 17, 2021

@swift-ci please smoke test

@tomerd tomerd added the ready Author believes the PR is ready to be merged & any feedback has been addressed label Sep 17, 2021
@tomerd tomerd self-assigned this Sep 17, 2021
// 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 {
Copy link
Contributor

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?

Copy link
Contributor Author

@tomerd tomerd Sep 17, 2021

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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.

@abertelrud abertelrud self-requested a review September 17, 2021 21:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Author believes the PR is ready to be merged & any feedback has been addressed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants