[llvm][object] Expose writeArchiveToStream

[Mogball]

This internal helper is a useful API to have, when one wants to write an archive directly to some other preallocated stream.

[llvmbot]

@llvm/pr-subscribers-llvm-binary-utilities

Author: Jeff Niu (Mogball)

Changes

This internal helper is a useful API to have, when one wants to write an archive directly to some other preallocated stream.

---

Full diff: https://github.com/llvm/llvm-project/pull/98254.diff

2 Files Affected:

• (modified) llvm/include/llvm/Object/ArchiveWriter.h (+7)
• (modified) llvm/lib/Object/ArchiveWriter.cpp (+5-4)

diff --git a/llvm/include/llvm/Object/ArchiveWriter.h b/llvm/include/llvm/Object/ArchiveWriter.h
index a19f8fcc79d74..e41b3d51173d4 100644
--- a/llvm/include/llvm/Object/ArchiveWriter.h
+++ b/llvm/include/llvm/Object/ArchiveWriter.h
@@ -48,6 +48,13 @@ enum class SymtabWritingMode {
   BigArchive64  // Only write the 64-bit symbol table.
 };
 
+// Write an archive directly to an output stream.
+Error writeArchiveToStream(raw_ostream &Out,
+                           ArrayRef<NewArchiveMember> NewMembers,
+                           SymtabWritingMode WriteSymtab,
+                           object::Archive::Kind Kind, bool Deterministic,
+                           bool Thin, std::optional<bool> IsEC = std::nullopt);
+
 Error writeArchive(StringRef ArcName, ArrayRef<NewArchiveMember> NewMembers,
                    SymtabWritingMode WriteSymtab, object::Archive::Kind Kind,
                    bool Deterministic, bool Thin,
diff --git a/llvm/lib/Object/ArchiveWriter.cpp b/llvm/lib/Object/ArchiveWriter.cpp
index 913b74c110b36..34f12cf0111cf 100644
--- a/llvm/lib/Object/ArchiveWriter.cpp
+++ b/llvm/lib/Object/ArchiveWriter.cpp
@@ -997,10 +997,11 @@ Expected<std::string> computeArchiveRelativePath(StringRef From, StringRef To) {
   return std::string(Relative);
 }
 
-static Error
-writeArchiveToStream(raw_ostream &Out, ArrayRef<NewArchiveMember> NewMembers,
-                     SymtabWritingMode WriteSymtab, object::Archive::Kind Kind,
-                     bool Deterministic, bool Thin, std::optional<bool> IsEC) {
+Error writeArchiveToStream(raw_ostream &Out,
+                           ArrayRef<NewArchiveMember> NewMembers,
+                           SymtabWritingMode WriteSymtab,
+                           object::Archive::Kind Kind, bool Deterministic,
+                           bool Thin, std::optional<bool> IsEC) {
   assert((!Thin || !isBSDLike(Kind)) && "Only the gnu format has a thin mode");
 
   SmallString<0> SymNamesBuf;

[jh7370]

@Mogball, why was a PR created for this and then immediately merged? Just trying to understand what you're trying to achieve.

[Mogball]

Hey thanks for taking a look! I found it odd that the only exposed APIs for writing a new archive were directly to a file or to a memory buffer. I have a use case where it would be more efficient to write directly to a stream to avoid copying out of the memory buffer. If you're not happy with this change, I'm more than willing to revert it for now

[jh7370]

No, I'm fine with the change actually (though I'd consider whether there's a way of having in-tree tests), but usually if you're putting something up for review, you don't immediately merge it into main before anybody has a chance to give that input, while if you think it doesn't need pre-commit review, you just push it directly without creating a PR, so I'm questioning the process you've gone through rather than the change itself.

[Mogball]

Thanks for letting me know! I'll be more mindful in the future. I can add a unit test as well

[dwblaikie]

This is documented here, btw: https://llvm.org/docs/CodeReview.html#code-review-workflow - if you did want to use a PR to run presubmits, there's a label you can apply that's just for documentation (in theory we could perhaps make the label suppress sending some notification emails, but haven't done that) so folks know your intent isn't to ask for precommit review/you believe this meets the bar (see documentation) for post-commit review.

[MaskRay]

I am also fine with exposing the API. If this helps some projects you are working on, it's best to mention the use case, though.
An in-tree use case is particular useful as otherwise there is always a risk that future contributors might notice this export unneeded and refactor code to internalize it again.