[Serialized diagnostics] Record generated buffer contents in diagnostics files #5901
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ics files Extend the format for serialized diagnostic files (`.dia`) to allow for the contents of source files to be included inside the diagnostic files themselves. This enables producers of diagnostics files that generate source code as part of their build (e.g., a compiler that performs macro expansion) to provide that generated source code to consumers of diagnostics, treating it like a normal file (e.g., with diagnostics pointing into it) that isn't otherwise recorded anywhere on disk. Source files with contents can, optionally, provide a source range that describes the "original" source range from which those contents are derived. This information is optional, but if present it can refer back to the source locations that triggered the creation of the generated source code, i.e., the use of a macro that caused macro expansion. This change extends the libclang C APIs with access to the source file contents (via `clang_getDiagnosticFileContents`) and the original source range (via `clang_getDiagnosticFileOriginalSourceRange`). The diagnostics file format, which has been stable for roughly a decade, is extended in a backward-compatible way by adding a new record, which existing clients (i.e., older libclang versions) will safely ignore. As such, we do not bump the diagnostics file format version at all. At present, the Swift compiler is the only producer of source file content records, which uses them to provide macro-expansion buffers. The Swift repository contains tests that produce these records and verify their correctness via `c-index-test`. We could consider introducing command-line flags to Clang to make it start producing these records, e.g., to capture macro-expansion buffers (as we're doing in Swift) or even to package up the contents of all source files that are referenced by serialized diagnostics, making the serialized-diagnostics file self-contained.
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test macOS |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Extend the format for serialized diagnostic files (
.dia) to allow for the contents of source files to be included inside the diagnostic files themselves. This enables producers of diagnostics files that generate source code as part of their build (e.g., a compiler that performs macro expansion) to provide that generated source code to consumers of diagnostics, treating it like a normal file (e.g., with diagnostics pointing into it) that isn't otherwise recorded anywhere on disk.Source files with contents can, optionally, provide a source range that describes the "original" source range from which those contents are derived. This information is optional, but if present it can refer back to the source locations that triggered the creation of the generated source code, i.e., the use of a macro that caused macro expansion.
This change extends the libclang C APIs with access to the source file contents (via
clang_getDiagnosticFileContents) and the original source range (viaclang_getDiagnosticFileOriginalSourceRange).The diagnostics file format, which has been stable for roughly a decade, is extended in a backward-compatible way by adding a new record, which existing clients (i.e., older libclang versions) will safely ignore. As such, we do not bump the diagnostics file format version at all.
At present, the Swift compiler is the only producer of source file content records, which uses them to provide macro-expansion buffers. The Swift repository contains tests that produce these records and verify their correctness via
c-index-test.We could consider introducing command-line flags to Clang to make it start producing these records, e.g., to capture macro-expansion buffers (as we're doing in Swift) or even to package up the contents of all source files that are referenced by serialized diagnostics, making the serialized-diagnostics file self-contained.
Implements the Clang side of rdar://103900370