This is an addition that landed in Go 1.12 but we couldn't use before
because we were supporting Go back until Go 1.11. It simplifies the code
around processes a bit.
This package does not implement any methods, which is of course not
useful. However, by creating this package in advance it's possible to
see the next issue that's preventing something from building in TinyGo.
Motivated by: https://github.com/tinygo-org/tinygo/issues/1634
A common error is when someone tries to export a blocking function. This
is not possible with the coroutines scheduler. Previously, it resulted
in an error like this:
panic: trying to make exported function async: messageHandler
With this change, the error is much better and shows where it comes from
exactly:
/home/ayke/tmp/export-async.go:8: blocking operation in exported function: messageHandler
traceback:
messageHandler
/home/ayke/tmp/export-async.go:9:5
main.foo
/home/ayke/tmp/export-async.go:15:2
runtime.chanSend
/home/ayke/src/github.com/tinygo-org/tinygo/src/runtime/chan.go:494:12
This should make it easier to identify and fix the problem. And it
avoids a compiler panic, which is a really bad way of showing
diagnostics.
This way is more consistent with how picolibc is specified and allows
generating a helpful error message. This error message should never be
generated for TinyGo binary releases, only when doing local development.
This LLVM version breaks CI and is now relatively rather old anyway, so
remove support for it.
This also reverts a workaround for LLVM 9, see a9568932b ("maixbit:
workaround to avoid medium code model").
Bump version to 1.1.2 in order to support darwin/arm64 within tinygo.
See bugst/go-serial#96 for more information.
Signed-off-by: Tobias Kohlbau <tobias@kohlbau.de>
This avoids external commands from finishing after the TinyGo command
exits. For example, when testing out compiler-rt on AVR, I got the
following error:
$ go install; and tinygo run -target=atmega1284p ./testdata/calls.go
[... Clang error removed ...]
error: failed to build /home/ayke/src/github.com/tinygo-org/tinygo/lib/compiler-rt/lib/builtins/extendsfdf2.c: exit status 1
error: unable to open output file '/tmp/tinygo361380649/build-lib-compiler-rt/ffsdi2.c.o': 'No such file or directory'
1 error generated.
That last error ("unable to open output file") is a spurious error
because the temporary directory has already been removed. This commit
waits until all running jobs have finished before returning, so that
these errors won't happen.
With this change, it is possible to fully use CGo on ESP32/ESP8266
chips. The following will work:
tinygo flash -target=d1mini -port=/dev/ttyUSB0 ./testdata/cgo/
tinygo flash -target=esp32-mini32 -port=/dev/ttyUSB0 ./testdata/cgo/
Previously it would produce output like the following:
/tmp/tinygo905539688/main.o:(.literal.runtime.run$1$gowrapper+0x150): undefined reference to `strcpy'
/tmp/tinygo905539688/main.o:(.literal.runtime.run$1$gowrapper+0x154): undefined reference to `strlen'
With this change, it is possible to compile ./testdata/float.go for the
ESP8266 and run it successfully. Previously it would result in many
linker error like this:
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0x0): undefined reference to `__unorddf2'
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0x4): undefined reference to `__gtdf2'
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0xc): undefined reference to `__nedf2'
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0x10): undefined reference to `__ltdf2'
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0x1c): undefined reference to `__gedf2'
I have verified that the output on the serial console matches
./testdata/float.txt when run on the ESP8266.
This flag is important for the Xtensa backend because by default a more
powerful backend (ESP32) is assumed. Therefore, compiling for the
ESP8266 won't work by default and needs the -mcpu flag.
This key was intended as some sort of cache key (as the name indicates)
but that never happened. Let's remove it to avoid clutter. The cacheLoad
and cacheStore functions are only used for C libraries (libc,
compiler-rt) so their caching behavior is a bit different from other
things worth caching.
This doesn't yet add support for actually making use of variadic
functions, but at least allows (unintended) variadic functions like the
following to work:
void foo();
