Unconditionally #include <future>

[GMNGeoffrey]

Summary

This unbreaks building with LLVM_ENABLE_THREADS=0. Since
https://github.com/llvm/llvm-project/commit/069919c9ba33 usage of
std::promise is not guarded by LLVM_ENABLE_THREADS, so this header
must be unconditionally included.

[GMNGeoffrey]

Note that I'm not familiar with this part of the codebase, so if there's a better fix (like we can add a guard to the std::promise usage) then I'm happy to do that instead. I'm just trying to maintain a LLVM_ENABLE_THREADS=0 build because of https://bugs.llvm.org/show_bug.cgi?id=44211.

[lhames]

Looks good to me. Thanks Geoffrey!

[hubert.reinterpretcast]

We've been building with LLVM_ENABLE_THREADS=0 to avoid dependencies on the TLS support in the build environment. We may require assistance to restore our builds if these patches introduce a TLS dependency. @daltenty, fyi.

[GMNGeoffrey]

In D89758#2340716, @hubert.reinterpretcast wrote:

We've been building with LLVM_ENABLE_THREADS=0 to avoid dependencies on the TLS support in the build environment. We may require assistance to restore our builds if these patches introduce a TLS dependency. @daltenty, fyi.

The specific usage is in ExecutionSession::lookupFlags. ExecutionSession::lookup is implemented with a non-threaded alternative. If you want to look at doing that it would be an alternative fix. I see other cases of #include <future> not guarded by LLVM_ENABLE_THREADS though: https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/llvm/llvm-project%24+%22%23include+%3Cfuture%3E%22+f:%5Ellvm/&patternType=regexp

[GMNGeoffrey]

Rebase on master

[GMNGeoffrey]

Hmmm seems this breaks lld on windows somehow... @lhames could you investigate a more principled fix? I think the approach of providing an alternative implementation if LLVM_ENABLE_THREADS is false would be consistent with other places in the file

[hubert.reinterpretcast]

In D89758#2340716, @hubert.reinterpretcast wrote:

We've been building with LLVM_ENABLE_THREADS=0 to avoid dependencies on the TLS support in the build environment. We may require assistance to restore our builds if these patches introduce a TLS dependency. @daltenty, fyi.

For information, the LLVM_ENABLE_THREADS=0 build we are using to avoid TLS support continues to work with this patch (and it does need this patch to avoid the failure from the missing include).

[GMNGeoffrey]

Rebase on master again

[lhames]

Hi Geoffrey,

Apologies for the delayed reply. Can you share details of the failure
you're seeing?

Regards,
Lang.

[GMNGeoffrey]

In D89758#2352745, @lhames wrote:

Hi Geoffrey,

Apologies for the delayed reply. Can you share details of the failure
you're seeing?

Regards,
Lang.

It was pre-merge failures on this revision. We concluded that they couldn't be related and proceeded with the merge.

llvm/lib/ExecutionEngine/Orc/Core.cpp

 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Config/llvm-config.h"
 #include "llvm/ExecutionEngine/Orc/DebugUtils.h"
 #include "llvm/ExecutionEngine/Orc/OrcError.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/MSVCErrorWorkarounds.h"
 
 #include <condition_variable>
-#if LLVM_ENABLE_THREADS
 #include <future>
-#endif
 
 #define DEBUG_TYPE "orc"
 
 namespace llvm {
 namespace orc {
 
 char ResourceTrackerDefunct::ID = 0;
 char FailedToMaterialize::ID = 0;