[CAS] Remove CAS dependency from LLVM_Utils module #11235
+351
−257
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
|
@swift-ci please test llvm |
benlangmuir
reviewed
Aug 21, 2025
|
|
||
| /// Get CASBackedFile for read. | ||
| virtual llvm::Expected<std::unique_ptr<CASBackedFile>> | ||
| openCASBackedFileForRead(const Twine &Path) = 0; |
There was a problem hiding this comment.
What's the reason for having this be a separate API instead of just using openFileForRead and cast<>ing the result to a CASBackedFile? Having both be virtual allows the posibility that a subclass returns different files from each one.
There was a problem hiding this comment.
Because CASBackedFileSystem implements openFileForRead for all underlying classes and underlying classes just need to implement openCASBackedFileForRead which returns a different file type. This allows user of CASBackedFileSystem to use a different API to avoid casting between File types.
cachemeifyoucan
force-pushed
the
eng/PR-cas-relayering
branch
2 times, most recently
from
4f6647b to
82d3f2b
Compare
|
@swift-ci please test llvm |
cachemeifyoucan
force-pushed
the
eng/PR-cas-relayering
branch
from
82d3f2b to
6cd1543
Compare
benlangmuir
approved these changes
Aug 26, 2025
Fix the proper laying of the llvm library by splitting CAS reference away from FileSystem references. This has some behavior changes: * The common base class for FileSystem configured with a CAS-backing is now `llvm::cas::CASBackedFileSystem` and migrate CAS related FileSystem APIs to the new class. * ThreadSafeFileSystem is folded into CASBackedFileSystem to avoid diamond class hierachies. * llvm::vfs::File needs to be RTTIExtended, so that a user can tell if the file is CAS backed when there are overlaying file system. * When configured with multi-layer CAS backed file system, the file content is available in every CAS along the way the file is resolved and the returned CASID is from the top layer. This is a more deterministic behavior than current one, that only the lowest level CAS has the reference, and user actually don't know which CAS it is associated with unless know in advance which layer vended the file.
cachemeifyoucan
force-pushed
the
eng/PR-cas-relayering
branch
from
6cd1543 to
145c6bd
Compare
|
@swift-ci please test llvm |
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.
Fix the proper laying of the llvm library by splitting CAS reference away from FileSystem references.
This has some behavior changes:
llvm::cas::CASBackedFileSystemand migrate CAS related FileSystem APIs to the new class.