fix(Storage): remove static-init-order dependency from Storage construction

[IvanaGyro]

Problem

Closes #673.

Storage::Init (inline, in the header) dispatched dtype construction through Storage_init_interface::USIInit[dtype], a static function-pointer table populated by the constructor of the global Storage_init_interface __SII object defined in src/backend/Storage.cpp. Because Storage::Init only touches the static table member — not __SII itself — a translation unit that instantiates Storage(size) without also referencing anything else from Storage.cpp (e.g. operator<<) has no guarantee that __SII's constructor has run before USIInit[dtype] is read: a static-initialization-order fiasco. When it hasn't run, USIInit[dtype] is still zero-initialized and Cytnx calls a null function pointer, segfaulting.

Fix

• Remove Storage_init_interface, __SII, and the USIInit table entirely — there is no more implicit global-initializer side effect to depend on.
• Replace it with init_storage(dtype), a plain function that folds over Type_list (skipping void) to find and construct the StorageImplementation<T> matching the requested dtype, mirroring the existing as_storage_variant_impl pattern already used in Storage.cpp. This keeps the supported dtype set single-sourced from Type_list instead of a hand-populated table.
• Update Storage::Init, Storage::_Loadbinary/the file-load path, and the GPU move/copy paths in cuMovemem_gpu.cu to call init_storage(dtype).
• Templatize Storage::_from_vector so callers that already know the element type T construct StorageImplementation<T> directly, instead of also routing through the (removed) runtime dtype table.
• Remove now-unused declarations and commented-out scaffolding tied to the old interface.

Testing

• ctest on debug-openblas-cpu and debug-mkl-cpu: all Storage suites pass (288/288); one pre-existing, unrelated ASan failure in BlockUniTensorTest.CombineBondForceDoesNotRewriteUserHeldBond reproduces identically on the pre-change base.
• pytest (Storage / dtype / mixed-dtype-arithmetic / rank-zero suites) passes against the rebuilt Python bindings.
• debug-openblas-cuda: compiles and links (cuMovemem_gpu.cu change) — compile-check only, no GPU available in this environment.
• pre-commit run clang-format (pinned v14) clean.

[gemini-code-assist]

Code Review

This pull request refactors the Storage initialization mechanism by replacing the legacy Storage_init_interface class and its global instance with a static array named storage_init_fns. This change simplifies the initialization logic and removes redundant code across multiple files, including updates to Tensor_impl and various backend implementations. The reviewer recommends using the inline keyword for the storage_init_fns array in the header file to ensure a single instance across translation units and prevent potential code bloat.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using static for storage_init_fns at namespace scope in a header file will create a separate copy of the array in each translation unit that includes this header. While this may work, it can lead to unnecessary code bloat.

Since the project targets C++20, you can use inline to ensure there is only one instance of this array across the entire program. This is the modern and correct way to define a global variable in a header file since C++17.

Suggested change

	static StorageInitFn storage_init_fns[N_Type] = {
	nullptr, SIInit_cd, SIInit_cf, SIInit_d, SIInit_f, SIInit_i64,
	SIInit_u64, SIInit_i32, SIInit_u32, SIInit_i16, SIInit_u16, SIInit_b};
	inline StorageInitFn storage_init_fns[N_Type] = {
	nullptr, SIInit_cd, SIInit_cf, SIInit_d, SIInit_f, SIInit_i64,
	SIInit_u64, SIInit_i32, SIInit_u32, SIInit_i16, SIInit_u16, SIInit_b};

[ianmccul]

The solution was already posted at #673 (comment)

[codecov]

Codecov Report

❌ Patch coverage is 94.73684% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 72.61%. Comparing base (f64b2f5) to head (d202f5f).
⚠️ Report is 45 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
include/backend/Storage.hpp	94.11%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1073      +/-   ##
==========================================
+ Coverage   72.11%   72.61%   +0.49%     
==========================================
  Files         225      226       +1     
  Lines       28207    28103     -104     
  Branches       71       71              
==========================================
+ Hits        20341    20406      +65     
+ Misses       7845     7676     -169     
  Partials       21       21              

Flag	Coverage Δ
cpp	72.72% <94.73%> (+0.50%)	⬆️
python	64.13% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
C++ backend	71.80% <94.73%> (+0.23%)	⬆️
Python bindings	77.75% <ø> (+1.95%)	⬆️
Python package	64.13% <ø> (ø)

Files with missing lines	Coverage Δ
include/backend/Tensor_impl.hpp	97.12% <ø> (ø)
src/backend/Storage.cpp	69.08% <100.00%> (ø)
src/backend/Storage_base.cpp	27.84% <ø> (ø)
src/backend/Tensor_impl.cpp	86.95% <ø> (ø)
include/backend/Storage.hpp	97.24% <94.11%> (-1.66%)	⬇️

... and 19 files with indirect coverage changes

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f64b2f5...d202f5f. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ianmccul]

This is an improvement over Storage_init_interface: it removes the dynamic
initialization bug from #673 and exposes the mechanism for what it is. But now
that #1015 has added Type_list, StorageImplementation<T>, and the typed
storage machinery, I think the proper endpoint is to remove the initializer
table entirely, rather than replace it with another hand-written enumeration
of the supported dtypes.

There should be two construction paths.

For code where T is already known, construct the typed implementation
directly:

template <CytnxType T>
boost::intrusive_ptr<StorageImplementation<T>>
make_storage(cytnx_uint64 size, int device, bool init_zero = true) {
  auto out = boost::intrusive_ptr<StorageImplementation<T>>(
    new StorageImplementation<T>());
  out->Init(size, device, init_zero);
  return out;
}

Eventually StorageImplementation<T> should have a suitable constructor and
the separate Init() call can disappear. This typed path should be used by
_from_vector<T>, typed kernels, and GPU helpers such as
cuMovemem_gpu<T>. Those callers already know T, so routing them back
through an integer dtype and a function-pointer table throws away the type
information unnecessarily.

A runtime-dtype factory is still needed for the public
Storage(size, dtype, device) API, Python, and deserialization. Generate that
factory from Type_list, which should be the single source of truth:

namespace internal {

template <std::size_t... Is>
boost::intrusive_ptr<Storage_base>
make_storage_impl(unsigned int dtype, cytnx_uint64 size, int device,
                  bool init_zero, std::index_sequence<Is...>) {
  boost::intrusive_ptr<Storage_base> out;

  const bool matched = (... || [&] {
    using T = std::variant_alternative_t<Is + 1, Type_list>;  // skip void
    if (dtype != Type_class::cy_typeid_v<T>) return false;

    out = make_storage<T>(size, device, init_zero);
    return true;
  }());

  cytnx_error_msg(!matched, "[Storage] invalid dtype %u.%s", dtype, "\n");
  return out;
}

}  // namespace internal

inline boost::intrusive_ptr<Storage_base>
make_storage(unsigned int dtype, cytnx_uint64 size, int device,
             bool init_zero = true) {
  constexpr std::size_t count = std::variant_size_v<Type_list> - 1;
  return internal::make_storage_impl(
    dtype, size, device, init_zero, std::make_index_sequence<count>{});
}

Then Storage::Init becomes simply:

this->_impl = make_storage(dtype, size, device, init_zero);

This removes:

• Storage_init_interface;
• __SII;
• SIInit_cd, SIInit_cf, etc.;
• storage_init_fns;
• the additional manually maintained enumeration of every supported dtype.

The fold above is one possible implementation; a compile-time-generated
function table would also work. The important points are that Type_list is
the only enumeration of supported types, and that typed callers do not go
through runtime dtype dispatch.

Until StorageImplementation<void> becomes the canonical empty state, the
runtime factory should reject Type.Void explicitly rather than leave a null
entry that can be called.

[IvanaGyro]

templatize these function, just let

p = new StorageImeplementation<T>(); // and Init
this->_impl = boost::intrusive_ptr(p)

[IvanaGyro]

I prefer to make this PR simple. There is no many function use this init function. I will preserve function table for the code that need large scope refactoring to use typed constructor directly. The places that are easy to templatize will be refactored.