[rebranch] Get Swift almost building with stable/20250601 #82243
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
AnthonyLatsis
requested review from
DougGregor,
Xazax-hun,
beccadax,
bnbarham,
egorzhdan,
fahadnayyar,
hamishknight,
hborla,
ian-twilightcoder,
j-hui,
nkcsgexi,
rintaro,
rjmccall,
slavapestov,
susmonteiro,
xedin,
xymus and
zoecarver
as code owners
AnthonyLatsis
commented
Jun 13, 2025
lib/ClangImporter/ClangImporter.cpp
Outdated
Comment on lines
4210
to
4223
Collaborator
Author
There was a problem hiding this comment.
This is probably the only change that I feel needs a review. @Xazax-hun Could you take a look?
Contributor
There was a problem hiding this comment.
Took a look, apart from a nit looks good to me. But just to double check, is this helper function that we used to use gone without any replacement? Although now at least we have a diagnostic for the failure case, which is great.
Collaborator
Author
There was a problem hiding this comment.
Yeah, it was refactored to accept an array of pairs. The splitting for compatibility with the old option is now done inline in the driver.
Collaborator
Author
|
@swift-ci please smoke test macOS |
Xazax-hun
reviewed
Jun 16, 2025
lib/ClangImporter/ClangImporter.cpp
Outdated
Comment on lines
4210
to
4223
Contributor
There was a problem hiding this comment.
Took a look, apart from a nit looks good to me. But just to double check, is this helper function that we used to use gone without any replacement? Although now at least we have a diagnostic for the failure case, which is great.
bnbarham
reviewed
Jun 17, 2025
lib/ClangImporter/ClangImporter.cpp
Outdated
Comment on lines
4210
to
4211
Contributor
There was a problem hiding this comment.
Can we find this out rather than add a fixme? Or add an issue and point to that instead. Otherwise this will just sit here forever more 😅 CC @benlangmuir
bnbarham
reviewed
Jun 17, 2025
…to... ...`clang::tooling::dependencies::DepscanPrefixMapping::configurePrefixMapper` See swiftlang/llvm-project#10723
…er,Writer}` subclasses See llvm/llvm-project#134142
drodriguez
added a commit
to drodriguez/swift
that referenced
this pull request
Nov 11, 2025
…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
added a commit
that referenced
this pull request
Nov 12, 2025
…r rebranch (#85445) 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 #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.
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.
No description provided.