rjmccall wrote: > If I'm understanding you correctly, no. The status quo is that we instantiate > constexpr-used functions at the point of use.
I meant that we could have a notion of "point of use" for constexpr functions that demands the current context itself be "sufficiently used" (for some definition thereof) before triggering instantiation. I believe we already have code to mark ODR uses retroactively within arbitrary statements. I suppose one problem with that is that we do sometimes need to trigger constant evaluation eagerly when checking function bodies, but maybe that's narrow enough that we could require the expression to be retroactively marked the same way. > And for a dash of extra spice, the standard says there are exactly two > permitted points of instantiation for `f<X>` Yes, this seems like it just needs to be fixed in the standard. It is unreasonable to say that all constant evaluation has to be delayed until the end of the TU. > Also, with C++ reflection just around the corner, we are fundamentally going > to need the "evaluate as a standards-mandated constant expression" mode for > the constant evaluator to grow the ability to talk to Sema, because lots of > the reflection operations do Sema-shaped things. So there's not really a way > to avoid the proxy here. Ah, that does change things. Good luck with your runaway committee. :) Let me know when the committee invents something that introduces arbitrary cyclic dependencies between declarations, and I'm sure Doug or I could tell you about our experience with request-based compiler architecture in swiftc. https://github.com/llvm/llvm-project/pull/173537 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
