Ayke

I did another update. I don't see why LLD and Clang would interfere with each other or with regular LLVM building/linking so I switched to more fine grained locks instead...

Ugh, builder/ar.go is really bad at properly closing files when there is an error. That may have triggered it.

We invoke lld in a separate process now so this is no longer an issue.

This is interesting, but I am actually considering something different: moving the generated files over to a separate repository (tinygo.org/device/stm32 etc) which can be used like a regular Go module....

> Keep in mind the package name would be `tinygo.org/x/device` or something like that. My thinking is that because the device package is so fundamental it's not really an "extra"...

@tlively A late reply from my side, now that I've discovered this issue. I'm hitting very similar issues as .NET with TinyGo (which is based on LLVM), which also has...

Some feedback from the Go side here on this proposal. I've been working on an alternative Go compiler (TinyGo) which also targets WebAssembly, hence my interest. There are three things...

Somewhat offtopic, but the last time I looked at the GC proposal it lacked a very important feature for Go, which is interior pointers. Even if they were implemented as...

> Go uses pointer-escape analysis to determine if something should be allocated on the stack or on the heap. This is not specified by the language, it's purely a heuristic...

> Tinygo would have to e.g. implement runtime.Stack(). For desktop systems I can see it happening some day, but for WebAssembly and embedded systems it probably won't happen. Because `runtime.Stack()`...