Skip to content

Deserialize diagnostics with no location correctly #213

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
May 10, 2021

Conversation

owenv
Copy link
Contributor

@owenv owenv commented May 7, 2021

When a diagnostic doesn't have a source location, no filename record will be emitted. This PR makes the filename of SourceLocation optional so these can be deserialized successfully.

@owenv
Copy link
Contributor Author

owenv commented May 7, 2021

@swift-ci please test

Copy link
Contributor

@abertelrud abertelrud left a comment

Choose a reason for hiding this comment

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

Looks good to me, but had one question about whether it's the filename or the whole source location that should be optional, semantically.

BTW, I'm really hoping to soon be able to start making use of this native ability to deserialize diagnostics files in SwiftPM. There are places where it's looking at the stderr of the compiler output and it's going to be great to start cleaning those up!

@@ -185,7 +185,7 @@ extension SerializedDiagnostics {

public struct SourceLocation: Equatable {
/// The filename associated with the diagnostic.
public var filename: String
public var filename: String?
Copy link
Contributor

Choose a reason for hiding this comment

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

What do the line and column mean (semantically) in the absence of a filename? If the .dia still has those fields without the filename then this does seem like the right change, but what should an IDE (for example) do with such a source location?

Copy link
Contributor

Choose a reason for hiding this comment

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

Or should this be modeled so that it's the SourceLocation itself that is optional? (even if that's indicated by just a nil filename field in the file).

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 updated this to just make the entire SourceLocation optional. Currently, Swift uses the absence of a filename to indicate either a missing or invalid location, and it's always paired with a line/column of 0. I'm fairly certain diagnostics formatted from Clang will look the same, but even if it encodes additional info there's really nothing an IDE can do to present that in a useful way.

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes a lot of sense to me. Thanks!

@owenv
Copy link
Contributor Author

owenv commented May 9, 2021

@swift-ci please test

@owenv
Copy link
Contributor Author

owenv commented May 9, 2021

@swift-ci please smoke test

@abertelrud
Copy link
Contributor

@swift-ci please test

@owenv
Copy link
Contributor Author

owenv commented May 10, 2021

@swift-ci please test Linux

@owenv
Copy link
Contributor Author

owenv commented May 10, 2021

error: module file '/home/buildnode/.cache/clang/ModuleCache/315MAVBT9WZMX/SwiftShims-339366MV89AHO.pcm' is out of date and needs to be rebuilt: signature mismatch\

@swift-ci please test Linux

@tomerd tomerd merged commit dd7b5a3 into swiftlang:main May 10, 2021
@tomerd
Copy link
Contributor

tomerd commented May 10, 2021

@owenv do you want to cherry pick this into release/5.5 too?

@owenv
Copy link
Contributor Author

owenv commented May 11, 2021

@tomerd thanks for merging! None of the higher-level tools use this code on the 5.5 branches, so I don't think it's worth cherry-picking.

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.

3 participants