This is an archive of the discontinued LLVM Phabricator instance.

Adding doWithCleanup abstraction
Needs ReviewPublic

Authored by beanz on Sep 22 2021, 12:01 PM.

Details

Reviewers
lhames
dblaikie
Summary

This patch adds a new doWithCleanup abstraction to LLVM that works
with llvm::Error, int, bool, and <insert your own type here>
return types that propagate status.

This abstraction is a more general way of having a conditional cleanup
that can be used with multiple return paths out of a function.

Test cases and a first use case in clang are part of the patch.

Diff Detail

Event Timeline

beanz created this revision.Sep 22 2021, 12:01 PM
beanz requested review of this revision.Sep 22 2021, 12:01 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptSep 22 2021, 12:01 PM
dblaikie added inline comments.Sep 30 2021, 8:52 PM
clang/lib/Frontend/FrontendAction.cpp
553–565

I guess this would be written as:

bool Success = BeginSourceFileImpl(CI, RealInput, HasBegunSourceFile))
if (!Success) {
  if (HasBegunSourceFile)
    CI.getDiagnosticClient().EndSourceFile();
  CI.clearOutputFiles(/*EraseFiles=*/true);
  CI.getLangOpts().setCompilingModule(LangOptions::CMK_None);
  setCurrentInput(FrontendInputFile());
  setCompilerInstance(nullptr);
}
return Success;

Which seems pretty legible - makes me unsure it's worth the complexity of building something like doWithCleanup, not that it's heinously complicated by any means - but all the traits stuff, etc.

& ideally/in general this'd usually be dealt with with some kind of RAII ownership model rather than such a strong stateful transition of an existing object that needs to be undone, rather than destroying an object.

llvm/include/llvm/Support/Cleanup.h
56–59

If this is going to be a template anyway, might as well use raw/generic/templated functor arguments and avoid the dynamic dispatch overhead of std::function? (or at least use llvm::function_ref)

llvm/unittests/Support/CleanupTests.cpp
19

Presumably doWithCleanup doesn't need to be called with an explicit template type argument most of the time/ever? It's probably good to test it in that way too, without passing the explicit template type argument.