Lîm Tsú-thuàn

@mewmew You can get the experimental implementation at [this commit](https://github.com/dannypsnl/llvm/commit/ac2baf5820d9c13291f0be568546aba18fceac9e), it only changes `ir.Func` BTW.

I suddenly realize we can embed `ir.Module` as a solution for use-cases mentioned here, should I close the issue?

For example, we want to generate a class handle, in the meanwhile affect our declaration~~~ ```go type EModule struct { *ir.Module } func (m *EModule) NewClass() *Class { return &Class...

Just thinking, maybe https://github.com/llir/llvm/issues/59#issuecomment-993037757 is not hopeless now with Generic concept in Go(actually union part). Previously, we must write ```go type Function interface { // ... } var _ Function...

Do we consider ANTLR? I was thinking so many issues you opened just cannot get fixed, maybe we should swap to a more stable parser generator? Anyway, it can't be...

Looks into the LLVM implementation: https://llvm.org/doxygen/IndirectionUtils_8cpp_source.html#l00286, it basically creates new instances from old values one by one. I also have no idea how to clone automatically correctly.

Do we have any updates here?

https://github.com/jinzhu/copier have a try?

Not pretty sure since I haven't tried it but maybe https://llvm.org/docs/CommandGuide/llvm-diff.html this can help?

According to [IBM developer document](https://developer.ibm.com/technologies/systems/articles/au-dwarf-debug-format/) > DWARF uses a series of debugging information entries (DIEs) to define a low-level representation of a source program. Each debugging information entry consists of...