spicy
spicy copied to clipboard
Bitfield not rejected in type decl
Currently the following code passes validation, but fails with an internal error when compiled:
# file: /tmp/bitfield.spicy
module foo;
type X = bitfield(32) {
x: 0..4;
};
$ spicyc -j /tmp/bitfield.spicy
|| - spicy::type::Bitfield (bitset.spicy:3:10-5:2) (non-const) (type-id: foo::X) (resolved) [@s:7f81cb412c60]
|| - type::UnsignedInteger <width="32"> (bitset.spicy:3:10-5:2) (const) (resolved) [@t:7f81cb411e70]
|| - type::Tuple <wildcard="false"> (bitset.spicy:3:10-5:2) (const) (resolved) [@t:7f81cb48ee30]
|| - type::tuple::Element (bitset.spicy:3:10-5:2) [@t:7f81cb48f120]
|| - ID <name="x"> (bitset.spicy:4:5) [@i:7f81cb48e010]
|| - type::UnsignedInteger <width="32"> (const) (resolved) [@t:7f81cb4120e0]
|| - spicy::type::bitfield::Bits <field_width="32" lower="0" upper="4"> (bitset.spicy:4:5) [@s:7f81cb412c00]
|| - ID <name="x"> (bitset.spicy:4:5) [@i:7f81cb412240]
|| - declaration::Expression %4 <linkage="private"> (bitset.spicy:4:5) [canon-id: foo::X::__dd] [@d:7f81cb412580]
|| - ID <name="__dd"> [@i:7f81cb4121d0]
|| - expression::Keyword <kind="$$"> (non-const) (resolved) [@e:7f81cb412170]
|| - type::UnsignedInteger <width="32"> (const) (resolved) [@t:7f81cb4120e0]
|| - node::None (bitset.spicy:4:5) [@n:7f81cb405fb0]
|| - type::UnsignedInteger <width="32"> (const) (resolved) [@t:7f81cb4120e0]
|| - node::None (bitset.spicy:4:5) [@n:7f81cb405fb0]
|| [internal-error] /private/tmp/bitset.spicy:3:10-5:2: codegen: type foo::X does not have a visitor
||
|| --- Aborting
|| # 0 libhilti.dylib 0x000000010fef0696 _ZN5hilti2rt9BacktraceC1Ev + 118
|| # 1 libhilti.dylib 0x000000010f87576b _ZN5hilti4util20abort_with_backtraceEv + 139
|| # 2 libhilti.dylib 0x000000010f86e6f7 _ZN5hilti6Logger13internalErrorERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEERKNS_8LocationE + 55
|| # 3 libhilti.dylib 0x000000010f8fdb8a _ZN5hilti6Logger13internalErrorINS_4TypeELPv0EEEvNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEERKT_ + 90
|| # 4 libhilti.dylib 0x000000010f8f97d4 _ZN5hilti6detail7CodeGen7compileERKNS_4TypeENS0_7codegen9TypeUsageE + 2244
|| # 5 libhilti.dylib 0x000000010f895ef5 _ZN5hilti6detail7visitor7VisitorIvN12_GLOBAL__N_114GlobalsVisitorENS_4NodeELNS1_5OrderE0EE8dispatchERKS5_ + 4053
|| # 6 libhilti.dylib 0x000000010f87f10b _ZN12_GLOBAL__N_114GlobalsVisitor15addDeclarationsEPN5hilti6detail7CodeGenERKNS1_4NodeERKNS1_2IDEPNS2_3cxx4UnitEb + 219
|| # 7 libhilti.dylib 0x000000010f87c26b _ZN5hilti6detail7CodeGen13compileModuleERNS_4NodeEPNS_4UnitEb + 891
|| # 8 libhilti.dylib 0x000000010fa50418 _ZN5hilti4Unit7codegenEv + 744
|| # 9 libhilti.dylib 0x000000010f9f862f _ZN5hilti6Driver13_codegenUnitsEv + 959
|| # 10 libhilti.dylib 0x000000010f9f96f7 _ZN5hilti6Driver12compileUnitsEv + 1447
|| # 11 libhilti.dylib 0x000000010f9fa2bd _ZN5hilti6Driver7compileEv + 45
|| # 12 libhilti.dylib 0x000000010f9f9df9 _ZN5hilti6Driver3runEv + 185
|| # 13 spicyc 0x000000010efa0467 main + 311
|| # 14 libdyld.dylib 0x00007fff72201cc9 start + 1
||
We should probably reject using a type decl with a bitfield
during validation, or alternatively add proper support for it.
Instead of rejecting bitfields here, we should add proper support instead, see the first sketch here.
As a workaround, one can put the bitfield
into a unit
and extract the bitfield
data after parsing; this allows reusing a single bitfield
declaration.
type BF = unit {
x: bitfield(8) {
x1: 0..7;
};
} &convert=self.x;
public type X = unit {
x: BF;
};