Bitfield not rejected in type decl

[bbannier]

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.

[bbannier]

Instead of rejecting bitfields here, we should add proper support instead, see the first sketch here.

[bbannier]

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;
};

[zeek-bot]

This issue has been mentioned on Zeek. There might be relevant details there:

https://community.zeek.org/t/internal-error-type-does-not-have-a-visitor/6856/2

[rsmmr]

Instead of rejecting bitfields here, we should add proper support instead, see the first sketch here.

I'll work on this, planing to make bitfields a full HILTI-side type with corresponding operations.