gauss_kronrod does not allow for non-literal types

Using gauss_kronrod with a non-literal type causes a compiler error.

lib/boost_1.81.0/boost/math/quadrature/gauss_kronrod.hpp:139:41: error: the type ‘const std::array<stan::math::var_value<double>, 8>’ of ‘constexpr’ variable ‘data’ is not literal
  139 |       static constexpr std::array<T, 8> data = {

Example godbolt here

https://godbolt.org/z/K4Mxa85Mz

I think a fix would be to detect if the type is literal for the gauss kronrod detail and have one implimentation that uses static constexpr arrays and the other uses arrays constructed at run time

@SteveBronder : Just to contextualize this for me: What is the goal of the stan::math::var_value<double> type? Also, why can't it be a literal type?

It's a scalar autodiff type used in the stan math library. Looking at the definitions for LiteralType it fails

a type with at least one constexpr (possibly template) constructor that is not a copy or move constructor,

The underlying memory for the var is made on a runtime arena allocator

I think for our purposes if gauss_kronrod allowed you to choose types for the weights/abscicca and a seperate type for the given functions return type then it would work for us and also fix the problem

a seperate type for the given functions return type

We do have a test for different return types:

math/test/gauss_kronrod_quadrature_test.cpp

Line 454 in ca29a70

Complex Q = integrator.integrate(lw, (Real) 0, pi<Real>());

But the arena allocator . . . that seems more difficult to support.

@jzmaddock : Any ideas of how to support this?

Any ideas of how to support this?

Maybe, I think some experimentation might be needed though...

But the arena allocator . . . that seems more difficult to support

The arena allocator is at global scope so it's not an issue.

I think just making a gauss kronrod detail that has something like std::enable_if_t<is_literal<T>::value> and another with the opposite would fix it

I think just making a gauss kronrod detail that has something like std::enable_if_t<is_literal::value> and another with the opposite would fix it

That involves a huge amount of duplication: I have a simpler solution working here, but I need to see if I can reduce bloat even further...