[Source, IR BE]: Is there any reason why some of the Impls of the IR elements are in ir.tree module ...

# compiler

[mcpiroman]

[Source, IR BE]: Is there any reason why some of the Impls of the IR elements are in ir.tree module and others in ir.tree.impl? The latter seem to only differ in that they contain and override IrFactory (also dunno why). In FIR, all Impls seem to lay in the tree module (but it is auto-gen, I know).

[dmitriy.novozhilov]

It's just because, I guess. There is no secret meaning behind it

[mcpiroman]

Tbh it just looked like so. Thanks

[bashor]

Some nodes have 2 implementations see ir.tree.impl and ir.tree.persistent, but for some nodes, we can have one common impl and they were kept in ir.tree. Separate modules were needed to prevent unintended usages.

[mcpiroman]

Separate modules were needed to prevent unintended usages.

So they are no longer? Am I free to merge it.tree.impl into ir.tree? (See KT-47294)

[dmitriy.novozhilov]

cc @udalov

[udalov]

It’s just because, I guess. There is no secret meaning behind it

It is not entirely correct. The idea was to separate normal and persistent impls, as @bashor mentioned, and make sure it’s explicit which modules depend on ir.tree.impl, which on ir.tree.persistent, and which on both.

[udalov]

The main point is basically that :compiler:backend.js does NOT depend on ir.tree.impl, and it should stay that way. So please keep it as a separate module.

[bashor]

@mcpiroman it would be better if you share more about your case.

[bashor]

I personally think it’s good to autogenerate these classes, but it may be tricky for external contribution.

[bashor]

Also, it’s important to keep current module structure for them.