This is an archive of the discontinued LLVM Phabricator instance.

[WIP][FileCollector] move Root creation
ClosedPublic

Authored by jkorous on Apr 27 2020, 12:57 PM.

Details

Summary

I might be missing something be since we aren't checking the return value of create_directories in constructor I'd say we can't really rely on that as part of the state.
Maybe we can just create it later and actually propagate the error? Or maybe just remove it completely as it'd get created in copyFiles when we iterate VFSWriter.getMappings()?

Diff Detail

Event Timeline

jkorous created this revision.Apr 27 2020, 12:57 PM
JDevlieghere accepted this revision.Apr 27 2020, 1:29 PM

This seems reasonable. Another alternative might be taking the error_code as an output argument if we want to be eager in creating the root directory. However, I think this is a better solution.

I probably added it to the ctor thinking that you'd rather fail early rather than when something goes wrong. For lldb for example it would be disappointing to reproduce a bug with reproducer capture enabled, only to find out at the last minute that we couldn't capture the files because we couldn't create the root. However, I don't think that's something we should optimize for. The reproducers will already create the reproducer root directory, and it seems unlikely that this would succeed, but then creating a subdirectory (the FileCollector root) would fail.

LGTM.

This revision is now accepted and ready to land.Apr 27 2020, 1:29 PM

For lldb for example it would be disappointing to reproduce a bug with reproducer capture enabled, only to find out at the last minute that we couldn't capture the files because we couldn't create the root.

Yes, this was the only reason I thought we might want to create it eagerly. Maybe we should then make existence of the dir (and maybe write access) an explicit requirement in doc comment and push this responsibility to client code? WDYT?

For lldb for example it would be disappointing to reproduce a bug with reproducer capture enabled, only to find out at the last minute that we couldn't capture the files because we couldn't create the root.

Yes, this was the only reason I thought we might want to create it eagerly. Maybe we should then make existence of the dir (and maybe write access) an explicit requirement in doc comment and push this responsibility to client code? WDYT?

I would keep the approach in the patch. If the directory already exists then create_directories is a no-op, so if the client wants to deal with the error eagerly they can, otherwise they can rely on copyFiles doing the right thing. It would be good to include that in the docs.

This revision was automatically updated to reflect the committed changes.