LTO & Consteval Functions: A Deep Dive

Hey guys! Let's dive into a fascinating corner of C++: how Link-Time Optimization (LTO) interacts with consteval functions in static libraries. Specifically, we're tackling the question of whether an executable can call a non-inline consteval function defined within a static library when LTO is in play. This is a juicy topic that touches on the core mechanics of compilation, linking, and the magic that is consteval. Buckle up, because we're about to get technical, but I promise to keep it conversational and engaging.

Understanding the Players: consteval, Static Libraries, and LTO

Before we get into the nitty-gritty, let's make sure we're all on the same page about the key players in this drama:

• consteval Functions: Introduced in C++20, consteval functions are a special breed. They are immediate functions, meaning they must produce a constant expression at compile time. If a consteval function cannot be evaluated at compile time, the program is ill-formed (it won't compile). This is a powerful tool for ensuring certain computations happen during compilation, leading to potential performance gains and compile-time error checking. Think of them as super-powered constexpr functions that are even more strict about compile-time evaluation.
• Static Libraries: These are collections of compiled code (object files) that are linked into your executable at link time. Unlike dynamic libraries (shared libraries), the code from a static library becomes part of your executable, increasing its size but eliminating runtime dependencies on external library files. They're like pre-packaged code modules that you can easily drop into your projects.
• Link-Time Optimization (LTO): This is where the magic really happens. LTO is a compiler optimization technique that delays code generation until link time. This allows the linker to see the entire program as a whole, rather than individual translation units (source files). With this global view, LTO can perform optimizations that wouldn't be possible otherwise, such as inlining functions across translation units, dead code elimination, and more. It's like giving the compiler a bird's-eye view of your entire project, allowing it to make smarter optimization decisions.

So, our core question boils down to this: Can LTO bridge the gap between an executable and a consteval function in a static library, even if that function isn't inlineable during the initial compilation of the executable's translation unit? Let's explore this further.

The Challenge: Non-Inline consteval Functions

The crux of the issue lies in the “non-inline” part. When a consteval function is defined in the same translation unit where it's called, or if it's defined as inline, the compiler has all the information it needs to evaluate the function at compile time. However, when a consteval function is defined in a separate translation unit within a static library and isn't marked as inline, the compiler might not be able to see its definition when compiling the calling code. This is because the compiler typically works on one translation unit at a time.

Without LTO, this would be a problem. The compiler wouldn't be able to evaluate the consteval function at compile time, and since consteval functions must be evaluated at compile time, the compilation would fail. The function's definition is hidden away within the compiled static library, inaccessible during the initial compilation phase of the calling code. This is the typical scenario where the compiler only sees declarations, not definitions, from other translation units.

This separation is a fundamental aspect of how traditional compilation works. Each .cpp file is compiled independently into an object file (.o or .obj), and these object files are then linked together to form the final executable. Without LTO, the compiler's view is limited to the current translation unit, making it impossible to