[Lldb-commits] [PATCH] D77602: [lldb/Reproducers] Support new replay mode: passive replay

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.


================
Comment at: lldb/include/lldb/Utility/ReproducerInstrumentation.h:305
     if (is_trivially_serializable<T>::value)
-      return;
+      return const_cast<T &>(t);
     // We need to make a copy as the original object might go out of scope.
----------------
JDevlieghere wrote:
> labath wrote:
> > What's up with the `const_cast` ? Should this maybe take a `T &t` argument and let `T` be deduced as `const U` when needed?
> I need to decode the template instantiation error for the details, but we need to return a non-const T. 
It would be good to at least know the reason for that, because const_casts smell..


================
Comment at: lldb/include/lldb/Utility/ReproducerInstrumentation.h:829-834
+                      &lldb_private::repro::construct<Class(Args...)>::record,
+                      args...);
+      recorder.RecordResult(c, false);
+    } else if (Deserializer *deserializer = data.GetDeserializer()) {
+      if (recorder.ShouldCapture()) {
+        lldb_private::repro::construct<Class(Args...)>::replay(
----------------
are you sure that the `lldb_private::repro::construct<Class(Args...)>::` qualifications are necessary here?


================
Comment at: lldb/source/API/SBReproducerPrivate.h:80-85
+      FileSpec file = l->GetFile<SBProvider::Info>();
+      static auto error_or_file = llvm::MemoryBuffer::getFile(file.GetPath());
+      if (!error_or_file)
+        return {};
+      static ReplayData r((*error_or_file)->getBuffer());
+      return {r.GetDeserializer(), r.GetRegistry()};
----------------
Could this be done in the initialization code somewhere (inside `Reproducer::Initialize`, I guess)? We could avoid static variables and get better error handling that way...


================
Comment at: lldb/unittests/Utility/ReproducerInstrumentationTest.cpp:91-95
+    return TestInstrumentationDataRAII(os);
+  }
+
+  static TestInstrumentationDataRAII GetReplayData(llvm::StringRef buffer) {
+    return TestInstrumentationDataRAII(buffer);
----------------
This works only accidentally because the compiler NRVO-s the temporary object. But that's not guaranteed to happen and could cause the `TestInstrumentationDataRAII` destructor to run twice. The simplest way to ensure the behavior you want is to return a `unique_ptr` to a constructed object (as well as delete all copy operations)...


================
Comment at: lldb/unittests/Utility/ReproducerInstrumentationTest.cpp:1044
+  }
+}
----------------
Maybe an EXPECT_DEATH test case for what happens when the replayed function calls don't line up?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77602/new/

https://reviews.llvm.org/D77602