Skip to content

Conversation

artemcm
Copy link
Contributor

@artemcm artemcm commented Sep 9, 2025

This change introduces a thread-safe version of the SerializedDiagnosticConsumer and refactors scanning compilation instance creation code to ensure this consumer gets added when the scanner query configuration command-line includes '-serialized-diagnostics-path' option.

This change ties creation of diagnostic consumers used with in-memory scanning to the same place where the scanner instance gets created, and ties their lifetime to the Scanner Query Context, generated in initCompilerInstanceForScan.

This change also adds a new-driver-only flag -dependency-scan-serialize-diagnostics-path to allow the driver to configure scanner-only serialized diagnostic output.

@artemcm
Copy link
Contributor Author

artemcm commented Sep 9, 2025

@swift-ci test

@artemcm artemcm force-pushed the InMemoryDepScanSerializedDiagnostics branch from e8da4b3 to 116d170 Compare September 10, 2025 15:15
@artemcm
Copy link
Contributor Author

artemcm commented Sep 10, 2025

@swift-ci test

@artemcm artemcm marked this pull request as ready for review September 10, 2025 21:42
Copy link
Contributor

@cachemeifyoucan cachemeifyoucan left a comment

Choose a reason for hiding this comment

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

LGTM function wise. Some comments inline.

std::unique_ptr<DepScanInMemoryDiagnosticCollector> InMemoryDiagnosticCollector;
/// A thread-safe serialized diagnostics consumer.
/// Note, although type-erased, this must be an instance of
/// 'ThreadSafeSerializedDiagnosticConsumer'
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think you need to type-erase to the base type. This can just be ThreadSafeSerializedDiagnosticConsumer

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I only did so because the existing SerializedDiagnosticConsumer infrastructure, and therefore also my extension, are both defined in SerializedDiagnosticConsumer.cpp implementation file. We could hoist them up to be in a header, but I wanted to match the existing pattern.

Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like ThreadSafeDiagnosticConsumer can be together with DiagnosticConsumer and we can just use this type here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't understand this comment, could you please be more specific?

ThreadSafeSerializedDiagnosticConsumer inherits from SerializedDiagnosticConsumer. The latter is implementation-only (defined in a .cpp). I modeled the former to match. What does "can be together with DiagnosticConsumer " mean?

Copy link
Contributor

Choose a reason for hiding this comment

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

I mean ThreadSafeDiagnosticConsumer that inherits from DiagnosticConsumer. We only need to make sure it is a ThreadSafeDiagnosticConsumer so we can add to scan instance. I don't see any upcast is needed to add here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are you referring to ThreadSafeDiagnosticCollector? Are you suggesting that ThreadSafeSerializedDiagnosticConsumer inherit both ThreadSafeDiagnosticCollector and SerializedDiagnosticConsumer?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, ok, I don't want to have a diamond here. Maybe I will model it as ThreadSafeDiagnosticConsumer with an internal SerializedDiagnosticConsumer, but you can't finish processing like that.

I will let you decide if you want to do it this way. Otherwise LGTM.

…consumer for in-memory scans

This change introduces a thread-safe version of the 'SerializedDiagnosticConsumer' and refactors scanning compilation instance creation code to ensure this consumer gets added when the scanner query configuration command-line includes '-serialized-diagnostics-path' option.
@artemcm artemcm force-pushed the InMemoryDepScanSerializedDiagnostics branch from 116d170 to b6760e7 Compare September 11, 2025 16:52
@artemcm
Copy link
Contributor Author

artemcm commented Sep 11, 2025

@swift-ci smoke test

@artemcm
Copy link
Contributor Author

artemcm commented Sep 12, 2025

@swift-ci smoke test

std::unique_ptr<DepScanInMemoryDiagnosticCollector> InMemoryDiagnosticCollector;
/// A thread-safe serialized diagnostics consumer.
/// Note, although type-erased, this must be an instance of
/// 'ThreadSafeSerializedDiagnosticConsumer'
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, ok, I don't want to have a diamond here. Maybe I will model it as ThreadSafeDiagnosticConsumer with an internal SerializedDiagnosticConsumer, but you can't finish processing like that.

I will let you decide if you want to do it this way. Otherwise LGTM.

@artemcm artemcm merged commit 926fc78 into swiftlang:main Sep 15, 2025
3 checks passed
@artemcm artemcm deleted the InMemoryDepScanSerializedDiagnostics branch September 15, 2025 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants