This is an archive of the discontinued LLVM Phabricator instance.

[Support] Make consumeError, toString callable from code compiled with RTTI.
AbandonedPublic

Authored by lhames on Oct 5 2021, 5:25 PM.

Details

Summary

This moves the toString(Error) function, and the failure-handling case of
consumeError, out-of-line. This enables calls to consumeError, toString,
errorToBool, and expectedToOptional from code compiled with RTTI turned on,
even if LLVM is built with RTTI turned off.

Diff Detail

Event Timeline

lhames created this revision.Oct 5 2021, 5:25 PM
lhames requested review of this revision.Oct 5 2021, 5:25 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 5 2021, 5:25 PM
lhames added a comment.Oct 5 2021, 5:33 PM

Vassil -- This is a generalization of the error fix that we discussed. Could you double check that it fixes the linker error that you saw?

After thinking about it for a while I'm on the fence about this approach -- on the one hand it's a reasonable cleanup, on the other hand I don't think we generally support linking -no-rtti LLVM libraries from -rtti code, and support for doing that (even partial support) might be an explicit non-goal for the project.

Another approach to fixing the example might just be to split it into two files. Pros of that approach: it deals with no-rtti/rtti crossover code The Right Way, Con: it complicates the example for everyone else.

Vassil -- This is a generalization of the error fix that we discussed. Could you double check that it fixes the linker error that you saw?

After thinking about it for a while I'm on the fence about this approach -- on the one hand it's a reasonable cleanup, on the other hand I don't think we generally support linking -no-rtti LLVM libraries from -rtti code, and support for doing that (even partial support) might be an explicit non-goal for the project.

Another approach to fixing the example might just be to split it into two files. Pros of that approach: it deals with no-rtti/rtti crossover code The Right Way, Con: it complicates the example for everyone else.

@lhames, thanks a lot for the patch -- this makes D107049 compile. I do not have a strong opinion on how/should we bridge rtti/no-rtti. I feel this will come up more often due to clang-repl...

Vassil -- This is a generalization of the error fix that we discussed. Could you double check that it fixes the linker error that you saw?

After thinking about it for a while I'm on the fence about this approach -- on the one hand it's a reasonable cleanup, on the other hand I don't think we generally support linking -no-rtti LLVM libraries from -rtti code, and support for doing that (even partial support) might be an explicit non-goal for the project.

Another approach to fixing the example might just be to split it into two files. Pros of that approach: it deals with no-rtti/rtti crossover code The Right Way, Con: it complicates the example for everyone else.

@lhames, thanks a lot for the patch -- this makes D107049 compile. I do not have a strong opinion on how/should we bridge rtti/no-rtti. I feel this will come up more often due to clang-repl...

Going via C also works for me:

diff
diff --git a/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp b/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
index 744a98bcdc87..fbdeddf0300b 100644
--- a/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
+++ b/clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp
@@ -25,6 +25,7 @@
 #include "llvm/ExecutionEngine/Orc/LLJIT.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/TargetSelect.h"
+#include "llvm-c/Error.h"
 
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -52,9 +53,7 @@ TEST(InterpreterTest, CatchException) {
     auto J = llvm::orc::LLJITBuilder().create();
     if (!J) {
       // The platform does not support JITs.
-      // We can't use llvm::consumeError as it needs typeinfo for ErrorInfoBase.
-      auto E = J.takeError();
-      (void)E;
+      LLVMConsumeError(llvm::wrap(J.takeError()));
       return;
     }
   }

I think that would be the least intrusive way to go...

lhames abandoned this revision.Oct 15 2021, 11:28 AM

Ok. I'm going to abandon this review -- we can revisit in the future if we find more instances of this issue.