[ClangImporter] Avoid use-after-free of clang::DiagnosticOptions after rebranch#85445
Merged
drodriguez merged 1 commit intoswiftlang:mainfrom Nov 12, 2025
Merged
Conversation
…r rebranch Upstream LLVM in llvm/llvm-project#139584 changed `DiagnosticOptions` from being a referenced counted object to just be a reference, not owned by the `clang::DiagnosticEngine`. In 0981b71 (part of swiftlang#82243), the usages of the Swift repository were adapted to the new memory model, but it introduced at least one use-after-free and a potential one around the usage of Clang in the Clang Importer. This commit tries to fix the use-after-free in both cases, by returning a `unique_ptr` to the `clang::DiagnosticOptions`, which makes the lifetime of the `DiagnosticOptions` match the lifetime of the variable that uses it (normally a `CompilerInvocation`). Other cases in 0981b71 should be safe because the lifetime of the `DiagnosticOptions` do not seem to propagate beyond the scope of the functions where they live (but I am not fully sure about the one in `IDETool/CompilerInvocation.cpp` completely). This was causing compiler crashes during the test `Interop/Cxx/stdlib/unsupported-stdlib.swift` which eventually uses `createClangDriver` and tries to emit a diagnostic, which in some cases was reading the memory from `DiagnosticOptions` when it was already out of scope.
drodriguez
requested review from
Xazax-hun,
artemcm,
beccadax,
egorzhdan,
ian-twilightcoder,
j-hui,
susmonteiro and
tshortli
as code owners
Contributor
Author
|
@swift-ci please smoke test |
egorzhdan
approved these changes
Nov 12, 2025
Contributor
egorzhdan
left a comment
egorzhdan
left a comment
There was a problem hiding this comment.
Thank you for discovering and fixing this!
Contributor
jansvoboda11
left a comment
jansvoboda11
left a comment
There was a problem hiding this comment.
Thanks for fixing this. Left a comment on ClangImporter::createClangInvocation(), but the rest looks good.
| std::unique_ptr<clang::CompilerInvocation> ClangImporter::createClangInvocation( | ||
| std::pair<std::unique_ptr<clang::CompilerInvocation>, | ||
| std::unique_ptr<clang::DiagnosticOptions>> | ||
| ClangImporter::createClangInvocation( |
Contributor
There was a problem hiding this comment.
I don't think this is necessary. clangDiags is a local, so diagOpts being local should be fine. The returned CI doesn't hold on to either of these.
Comment on lines
+554
to
+555
| /// Clang diagnostic options used to create the Clang invocation. | ||
| std::unique_ptr<clang::DiagnosticOptions> DiagnosticOptions; |
Contributor
There was a problem hiding this comment.
Suggested change
| /// Clang diagnostic options used to create the Clang invocation. | |
| std::unique_ptr<clang::DiagnosticOptions> DiagnosticOptions; | |
| /// Clang diagnostic options used to create the Clang driver. | |
| std::unique_ptr<clang::DiagnosticOptions> DiagnosticOptions; |
The invocation doesn't need external DiagnosticOptions.
Contributor
Author
|
I will remove the pieces that touched |
drodriguez
added a commit
to drodriguez/swift
that referenced
this pull request
Nov 12, 2025
…swiftlang#85445) Feedback in swiftlang#85445 after it merged pointed out that the changes around `createClangInvocation` are not necessary because `CompilerInvocation` do not hold a reference to `clang::DiagnosticOptions`, only the `clang::driver::Driver` does. These changes undo the modifications done there and return the code to the previous state (but keeps the changes around `createClangDriver` which was causing the use-after-free).
Contributor
That's right. |
drodriguez
added a commit
that referenced
this pull request
Nov 13, 2025
…#85445) (#85457) Feedback in #85445 after it merged pointed out that the changes around `createClangInvocation` are not necessary because `CompilerInvocation` do not hold a reference to `clang::DiagnosticOptions`, only the `clang::driver::Driver` does. These changes undo the modifications done there and return the code to the previous state (but keeps the changes around `createClangDriver` which was causing the use-after-free).
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Upstream LLVM in llvm/llvm-project#139584 changed
DiagnosticOptionsfrom being a referenced counted object to just be a reference, not owned by theclang::DiagnosticEngine.In 0981b71 (part of #82243), the usages of the Swift repository were adapted to the new memory model, but it introduced at least one use-after-free and a potential one around the usage of Clang in the Clang Importer.
This commit tries to fix the use-after-free in both cases, by returning a
unique_ptrto theclang::DiagnosticOptions, which makes the lifetime of theDiagnosticOptionsmatch the lifetime of the variable that uses it (normally aCompilerInvocation).Other cases in 0981b71 should be safe because the lifetime of the
DiagnosticOptionsdo not seem to propagate beyond the scope of the functions where they live (but I am not fully sure about the one inIDETool/CompilerInvocation.cppcompletely).This was causing compiler crashes during the test
Interop/Cxx/stdlib/unsupported-stdlib.swiftwhich eventually usescreateClangDriverand tries to emit a diagnostic, which in some cases was reading the memory fromDiagnosticOptionswhen it was already out of scope.