"incompatible types" error on constructor `_root` parameter when importing type from other KSY file

[pfroud]

Here's one KSY file:

meta:
  id: first_ksy_file
  imports:
    - second_ksy_file
seq:
  - id: foo
    type: "second_ksy_file::type_in_second_ksy_file"

Here's another KSY file:

meta:
  id: second_ksy_file
types:
  type_in_second_ksy_file:
    seq:
      - id: bar
        type: u1

In the read() method of FirstKsyFile.java, this line:

this.foo = new SecondKsyFile.TypeInSecondKsyFile(this._io, this, _root);

has this error on the third argument:

incompatible types: FirstKsyFile cannot be converted to SecondKsyFile

The constructor we're trying to call is:

public TypeInSecondKsyFile(KaitaiStream _io, FirstKsyFile _parent, SecondKsyFile _root) { ... }

In an answer on StackOverflow, GreyCat says this should be possible: Referencing Kaitai Struct file (ksy) in external ksy file in Kaitai Struct

Should I edit the generated Java code to use the two-argument constructor of TypeInSecondKsyFile (which does not have the _root parameter) instead?

Or maybe the KS compiler should make the type of the _root parameter be KaitaiStruct?

[hjmallon]

The same problem happens with the C++ cpp_stl generator and it causes compile failures. Also the #include paths are not correctly added.

[akatatsu27]

the same issue is present in c#. I have a .ksy file with "extra" types that I reuse in multiple files regularly. a single import statement of that one file, and scoping with "::" is much cleaner than making each type a separate file, and having to resolve multiple imports. The kaitai compiler allows this, and throws no error, but the generated code is filled with errors.
A simple solution seems to be to use the base class KaitaiStruct in the constructor definition instead of the generated from the meta id class

[generalmimon]

Yeah, as evidenced by occurrences of the same problem in other languages, it doesn't seem to be specific to Java, so I'll rename the issue.

[Mingun]

I think, this is duplicate of #414.

[generalmimon]

@Mingun:

I think, this is duplicate of #414.

No, it's not. #414 has no mention of imports. The Java error might look similar to #961 (or #414), but should be resolved differently: when imports are involved, _parent and _root should be omitted because individual .ksy specs should be self-sufficient, not change their behavior (and the generated code) depending on from where they're imported or whether they're imported at all.