"Cannot getTypeInfo() on a type that is unsized!" error on jitclass with typed.Dict variable that has deferred type as value type

Numba Community Support
1

Hello community, I am writing the code as follows,

import numba as nb
from collections import OrderedDict
from numba import deferred_type, optional
from numba.experimental import jitclass
from numba import types

node_type = deferred_type()

@jitclass([
  ('parent', optional(node_type)),
  ('children', types.DictType(types.int32, node_type)),
])
class TreeNode(object):
    def __init__(self, parent=None):
        self.parent = parent
        self.children = nb.typed.Dict.empty(types.int32, node_type)

node_type.define(TreeNode.class_type.instance_type)

TreeNode(1)

However this is giving me:

python3: /root/miniconda3/conda-bld/llvmdev_1596720471173/work/lib/IR/DataLayout.cpp:705: llvm::Align llvm::DataLayout::getAlignment(llvm::Type*, bool) const: Assertion `Ty->isSized() && “Cannot getTypeInfo() on a type that is unsized!”’ failed.

Am I doing anything wrong or this is not yet supported by numba? If latter is the case would u describe any workaround for this? Thanks in advance!

1 Like
2

Getting the same problem with a typed.List.empty_list(some_deferred_type)

3

Regardless of whether you’re doing something wrong, Numba shouldn’t be causing assertions to fail and bringing the whole Python interpreter down :slightly_smiling_face: - I’ve created Abort with 'Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed' · Issue #8404 · numba/numba · GitHub for tracking / investigating this.

4

With the workaround from llvmlite assertion when using deferred type as typed dict values · Issue #8404 · numba/numba · GitHub I’m now getting:

numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Failed in nopython mode pipeline (step: native lowering)
Cannot cast int64 to OptionalType(DeferredType#139935458142016): i64 %"arg.parent"
During: lowering "(self).parent = parent" at /home/gmarkall/numbadev/issues/discourse-1191/original.py (15)
During: resolving callee type: jitclass.TreeNode#7f44fdcbee30<parent:OptionalType(DeferredType#139935458142016),children:DictType[int32,DeferredType#139935458142016]<iv=None>>
During: typing of call at <string> (3)

During: resolving callee type: jitclass.TreeNode#7f44fdcbee30<parent:OptionalType(DeferredType#139935458142016),children:DictType[int32,DeferredType#139935458142016]<iv=None>>
During: typing of call at <string> (3)

which may be indicative of another bug - looking into this too.

5

OK, it turns out that was just a bug in the example - parent is a node type but it was being passed an integer. If we construct two nodes so that one can be the parent of the other, like:

import numba as nb
from numba import deferred_type, optional
from numba.experimental import jitclass
from numba import types

node_type = deferred_type()


@jitclass([
  ('parent', optional(node_type)),
  ('children', types.DictType(types.int32, node_type)),
])
class TreeNode(object):
    def __init__(self, parent=None):
        self.parent = parent
        self.children = nb.typed.Dict.empty(types.int32, node_type)


node_type.define(TreeNode.class_type.instance_type)

t = TreeNode()
t2 = TreeNode(t)

then this runs to completion with the workaround.