The file collector class is useful for creating reproducers, not just for LLDB, but for other tools. That's why it should live in LLVM. I'm planning to use it in Clang to generate reproducers for clang-scan-deps.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/include/llvm/Support/FileCollector.h | ||
---|---|---|
40 ↗ | (On Diff #211574) | TLDR: private? I'm just wondering if we could make the class safer or the correct use more obvious for classes deriving from it (if we want to support that). The couple protected members and methods seem suggesting it's fine to use these from a derived class implementation. IIUC m_mutex is guarding m_vfs_writer, m_seen and m_symlink_map and while it is being locked in implementation of public method AddFile, protected methods seem to be assuming their callers lock the mutex. Specifically there's a potential for a data race in AddFileImpl (calling GetRealPath which uses m_symlink_map) and in AddFileToMapping if either is called directly from a derived class. Since lldb_private::FileCollector seems to be using only the public interface we might just declare the above private (and maybe add a doc comment when caller of a method is expected to lock the mutex)? |