[llvm] [llvm] Support building with c++23 (PR #154372)

[Kyle Krüger via llvm-commits]

================
@@ -36,7 +36,7 @@ class MachineFunctionAnalysis
     std::unique_ptr<MachineFunction> MF;
 
   public:
-    Result(std::unique_ptr<MachineFunction> MF) : MF(std::move(MF)) {}
+    Result(std::unique_ptr<MachineFunction> MF);
----------------
kykrueger wrote:

In this comment it also seems like the clang team does not intend on changing their implementation to avoid such errors: 
> This would seem to require that we instantiate `constexpr` functions on-demand, when they are actually called during constant evaluation, rather than performing the instantiations in advance of constant evaluation[1]. This has various problems:
> 
> 
> 
> - It breaks layering: constant evaluation needs template instantiation and hence all of `Sema`. This is a problem for uses of the Clang AST library, which is not allowed to depend on Sema but contains constant evaluation. For example, this is a problem for code generation, which should not assume there's still a Sema instance around but needs to perform constant evaluation. It's probably feasible to handle this, by adding an *optional* callback from constant evaluation into template instantiation, and only providing it in the cases of language-semantics-required constant evaluations performed from `Sema`.
> 
> - It breaks instantiation depth: during a deeply-recursive constant evaluation, we would be able to trigger a template instantiation, which could result in a deeply-recursive constant evaluation, that then triggers another template instantiation, and so on. This dramatically increases the potential stack depth per template instantiation "step", which seems likely to run us out of stack in a way that our existing guards against this problem won't catch.
> 
> - It breaks the desirable language property that constant evaluation is free of side-effects. If constant evaluation can trigger template instantiation, then it becomes observable and whether a certain subexpression was evaluated can have effects on the behavior of the program. This is also mitigated to some extent by only triggering template instantiation from constant evaluations that are required by the language semantics, so that speculative evaluations used to drive warnings, and enabling warning flags, don't change the program behavior, but will require significant caution.
> 
> 
> 
> This is not to say that we shouldn't do it, but it's not trivial, and these concerns led to the language rules explicitly accommodating implementations that want to eagerly instantiate constexpr functions on first use.
> 
> 
> 
>  [1]: I think there is actually another strategy that we could take. We could track a call graph of `constexpr` functions, like we do for CUDA, then when Sema is about to kick off a language-semantics-required constant evaluation, it could quickly scan the expression for function references and instantiate those functions plus anything reachable from them in the call graph that is not yet instantiated. That would avoid the instantiation depth problem and the layering problem, at least, and because it'd be an explicit step taken by Sema it'd be less likely that an implementation of a warning flag would accidentally trigger template instantiation. But it'd come with additional storage costs. 

 _Originally posted by @zygoloid in [#59966](https://github.com/llvm/llvm-project/issues/59966#issuecomment-1397716263)_

https://github.com/llvm/llvm-project/pull/154372