compiler not support "contents" key in Attribute spec

[iabdurrahman]

based on document in http://doc.kaitai.io/ksy_reference.html#attribute-contents (2018-12-20), Attribute spec may contain "contents" key. but ksc throw error when compiling file containing "contents" key in seq

example ksy file:

meta:
  id: socksv5_method
  title: SOCKSv5 Method packet (RFC 1928)
  endian: be
doc: |
  packet format for message identifier/method selection for SOCKSv5
seq:
  - id: ver
    doc: "SOCKS version, must 0x05"
    type: u1
    contents:
      - 0x05
  - id: nmethod
    doc: "length of supported SOCKSv5 method"
    type: u1 
  - id: method
    doc: "SOCKSv5 client supported method (authentication), length equal to nmethod"
    type: u1
    repeat: expr
    repeat-expr: nmethod

but compiler show error (compile to python class): /seq/0/contents: unknown key found, expected: consume, doc, doc-ref, eos-error, id, if, include, repeat, terminator, type

compiler version: kaitai-struct-compiler 0.9-SNAPSHOT

java version:

java 10.0.2 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

I want kaitai struct stop parsing data when some field value is invalid.

[iabdurrahman]

it compiled when "type" removed, so ksy file become:

meta:
  id: socksv5
  title: SOCKSv5 Method packet (RFC 1928)
  endian: be
doc: |
  packet format for message identifier/method selection for SOCKSv5
seq:
  - id: ver
    doc: "SOCKS version, must 0x05"
    contents: [0x05]
  - id: nmethod
    doc: "length of supported supported SOCKSv5 method"
    type: u1 
  - id: method
    doc: "SOCKSv5 client supported method (authentication), length equal to nmethod"
    type: u1
    repeat: expr
    repeat-expr: nmethod

my bad, you can close this issue

[KOLANICH]

Anyway, the compiler error messages are a bit misleading, it should warn that usage of type excludes usage of contents

[GreyCat]

Actually, this is a good point. I don't like current compiler's message as well, as while it's technically correct:

• it's overly verbose — i.e. it lists all possible keys, and it changes quite often as we add support for new ones
• it's somewhat confusing for end user, as it does not really state why we came to this conclusion and what to do next.

Any ideas?

[iabdurrahman]

I'm not familiar with scala, but it seems in kaitai_struct_compiler/shared/src/main/scala/io/kaitai/struct/format/AttrSpec.scala, contents key valid when data type is byte array (in AttrSpec object definition).

and when byte array is used as data type, type should not declared. it is confusing because documentation mention type and contents are common key in attribute spec.

IMHO documentation should be updated to follow code implementation. for compile error message, may be something like this is quite informative: (when compiler parse type and then contents: ) key "contents" only for byte array type, but type is: <value of type key> or (when compiler parse contents and then type: ) and previous key "contents" assume type is byte array, but type redeclared as: <value of type key>