The Linux, macOS and Windows workflows build every file that a release
needs when the release branch is pushed. The new Release workflow finds
those runs for the tagged commit, waits for them, and collects their nine
files into a draft release. It builds nothing, so what ships is what was
tested.
The release notes come from the CHANGELOG.md entry for that version.
Signed-off-by: Ron Evans <ron@hybridgroup.com>
The Actions cache of the repository was at 10.24 GB against a quota of
10 GB, so GitHub removed entries by least recent use. The LLVM entries
were among the first to go, and CI then built LLVM again although the
LLVM version did not change.
The Docker buildx layer blobs held 6.0 GB of the quota. All LLVM caches
together held 1.97 GB. Move the Docker layer cache to a registry cache in
GHCR, which does not use the Actions quota. Both jobs have the necessary
permission and login already.
Pin the LLVM commit in llvm-version.txt and fetch that commit, in place
of a clone of the branch tip tinygo_22.x. Add a hash of that file to each
LLVM cache key, so a change of the LLVM version invalidates the caches
and no other change does.
Also rename the LLVM image tags from llvm-20 to llvm-22.
* pinout yamls removed
* machine: implement default UART pin configuration for Embedfire boards
* flash command moved to chip level so VS Code plugin can select bare chip
* machine: add support for alternate pin mode configuration
* add build targets for embedfire on py32
* add support for embedfire target in GNUmakefile for py32
* lib/py32-svd: remove duplicate DBGMCU.IDCODE CODE field
Update submodule to fix duplicate SetIDCODE/GetIDCODE method
declarations in the generated py32f002bxx.go device file.
* update subproject commit reference in py32-svd
* refactor: update CPU frequency handling in machine and runtime packages
* refactor: replace ConfigureUARTPin function with direct pin configuration in UART setup
* SetAltFunc documentation for GPIO pin alternate functions
* refactor: improve UART write and flush error handling with timeout
* machine/py32: generalize UART driver to any USART
Add a per-instance setup func to the UART type so the driver is no longer
hardwired to USART1. DefaultUART stays USART1; add UART2 (USART2) in a
separately build-tagged file since py32f002x parts lack USART2. RX IRQ
handlers reference runtime-assigned vars to break the init cycle, and setup
is assigned in the var initializer so it runs before InitSerial.
Add the py32f003_32k_4k target (32K flash / 4K RAM).
* Add canonical PY32F002, F003, and F030 density targets
Use CMSIS/pyocd device names for target files and build tags. Add all F003 and F030 densities plus F002A/B, correct F002B to 24K flash and its own startup file, fix the F030x8 pyocd target, and update Embedfire inheritance.
* Add targets for all PY32 CMSIS devices
* Support all PY32 register layout variants
* machine/py32: use generated register definitions
* machine/py32: fix alternate-function documentation
* machine/py32: report the configured CPU frequency
* machine/py32: use unsafe.Add for GPIO ports
* machine/py32: bound and yield UART polling
* machine/py32: configure UART pins from UARTConfig
* build: use the current PY32 SVD repository URL
* test: cover PY32 UART register layouts
* machine/py32: restore dynamic CPU frequency tracking
* machine/py32: share the USART TX-ready bit
* targets/py32: scale system stacks with RAM
* machine/py32: keep clock state internal
* targets/py32: normalize generated metadata
* machine/py32: normalize GPIO configuration
* machine/py32: fix T020 UART setup
* machine/py32: reduce clock variant files
* machine/py32: clean up UART variants
* machine/py32: decouple UART clock capability
* lib/py32-svd: use organization repository
* runtime/py32: name 24MHz HSI encodings
* machine/py32: derive startup clock from capability
* machine/py32: use generated USART clock mask
* machine/py32: name T020 8-bit UART mode
* ci: include PY32 in sharded smoke tests
* runtime: remove PY32 HSI frequency workaround
* GNUmakefile: split into topic files in make/
The GNUmakefile had 1295 lines and mixed build configuration, LLVM
bootstrapping, device generation, four test suites, the smoke tests,
release packaging, and lint tools. The smoke tests alone were 500 lines.
Move each part into its own file in make/ and include them from
GNUmakefile. config.mk must be included first because the other files
use its variables in immediate assignments and conditionals.
There is no change in behavior. The parsed make database is identical
for the default build and for ASSERT=1, STATIC=1, XTENSA=0, STM32=0,
WASM=0, and CROSS=aarch64-linux-gnu, except for MAKEFILE_LIST and the
.PHONY list, which now also includes targets that were phony but not
declared.
The Dockerfile copies GNUmakefile alone before it builds LLVM, to keep
that layer independent of the source tree. It must copy make/ too.
* make/smoketest.mk: split into groups and add smoketest-quick
The smoke test was one recipe of about 500 lines with 236 builds that
always ran in sequence. Split it at the group boundaries that were
already there, so that:
- `make -j smoketest` builds the groups in parallel. A full run goes
from 325 to 91 seconds on a 32 core machine.
- CI can shard the groups across runners.
Each group writes to its own name in build/smoke/, because all builds
wrote to test.hex before and would overwrite each other in a parallel
build. The output extension selects the format, so it stays per line.
Add smoketest-quick, which builds one board for each processor
architecture. The full smoke test answers "can TinyGo build for every
board", which does not depend on the host OS, so it only needs to run
on one OS. The other jobs use smoketest-quick.
The comment above the esp32c3 group had 4 spaces of indentation instead
of a tab. That was harmless in the middle of a recipe, but it is now the
first line of a group, where it would stop the recipe from starting.
The set of build commands is unchanged for the default flags and for
XTENSA=0, STM32=0, and WASM=0. All 226 checksums are the same as before,
for a sequential build and for `make -j16`.
* ci: run the full smoke test once, on Linux only
The smoke test ran six times for each push: twice on Linux, twice on
macOS, once on Windows, and once in the compatibility test. Together
that was about 97 minutes of the CI time.
The smoke test checks that TinyGo can build a binary for each board.
That does not depend on the host OS. The only part that does is one
build behind a Windows check.
Add a smoketest-linux job that runs the full set, split across four
runners that use the tarball from the build-linux job. The groups are
balanced with the measured build time of each group. Remove the full
smoke test from test-linux-build, which the new job replaces, and use
smoketest-quick for the other four jobs.
Expected result: about 55 to 39 minutes for the slowest workflow, and
about 97 to 35 minutes of total smoke test time.
* make/smoketest.mk: build nintendoswitch in smoketest-quick
It is the only target that uses the aarch64 LLVM triple. With it,
smoketest-quick covers all 13 triples that the full smoke test uses.
Go 1.27 adds generic methods (golang/go#77273). golang.org/x/tools
go/ssa v0.42.0 does not instantiate them: objectMethod only applies
receiverTypeArgs and ignores method-level type parameters, so a call
such as (*math/rand/v2.Rand).N resolves to the abstract generic method
and its body reaches createConst with a type-parameter-typed zero
constant, triggering "panic: expected nil interface constant".
Upgrade golang.org/x/tools to v0.47.0, whose go/ssa returns nil from
MethodValue for generic methods and instantiates method-level type
parameters. No compiler changes are required.
Since x/tools v0.47.0 requires Go 1.25, raise the minimum supported Go
version from 1.24 to 1.25.
Signed-off-by: deadprogram <ron@hybridgroup.com>
* wasm: patch wasm_exec.js and wasm_exec_node.js from Go 1.18+
Port this commit https://github.com/golang/go/commit/680caf15355057ca84857a2a291b6f5c44e73329 removing polyfills from `wasm_exec.js`, now the environment is expected to provide all the required polyfills.
`wasm_exec.js` now only provides stub fallbacks for globalThis.fs and globalThis.process.
All NodeJS specific code is now in a separate file `wasm_exec_node.js` with its required polyfills.
* feat: bump minimum node version to 22
Drops official support for NodeJS 18 for WASM by removing the provided polyfills in the `wasm_exec.js`.
Now the environment is expected to provide the polyfill if it is running on older NodeJS versions
The new minimum required version for WASM is NodeJS 22+.
* chore: removed wrong comment
`wasm_exec_node.js` no longer contains the polyfill for NodeJS 18
This has the following effects:
* It fixes issue #5414.
* It bumps the minimum Go version to Go 1.24 (from 1.23).
I looked, and there doesn't seem to be a version of golang.org/x/tools
that supports the improved `new` builtin without also bumping the
minimum Go version.
Now that the drivers repo and friends are intended to target the most
recent release version of TinyGo instead of the development version,
this trigger does not serve any puppose to trigger a build that will have
already been tested.
Signed-off-by: deadprogram <ron@hybridgroup.com>
the test-macos-homebrew job, and it conflicts with the actual build
that we want, which is macOS 14 for backwards-compatibility.
Signed-off-by: deadprogram <ron@hybridgroup.com>
- do not install cmake, instead use the version already installed
- add macOS 15 to the CI builds
- update a could of GH actions to latest release
- update Go version being use to Go 1.25.1
Signed-off-by: deadprogram <ron@hybridgroup.com>
This switches the Espressif fork from LLVM 19 to LLVM 20, so we can use
the improvements made between those LLVM versions. It also better aligns
with the system-LLVM build method, which currently also defaults to LLVM
20.
Note that this disables the machine outliner for RISC-V. It appears
there's a bug in there somewhere, with the machine outliner enabled the
crypto/elliptic package tests fail with -target=riscv-qemu.
This should ideally be investigated and reported upstream.
With these flags, the TinyGo binary gets 18.8MB (11.6%) smaller. That
seems like a quite useful win for such a small change!
This is only for Linux for now. MacOS and Windows can be tested later,
the flags for those probably need to be modified.
Originally inspired by:
https://discourse.llvm.org/t/state-of-the-art-for-reducing-executable-size-with-heavily-optimized-program/87952/18
There are some other flags like -Wl,--pack-dyn-relocs=relr that did not
shrink binary size in my testing, so I've left them out.
This also switches the linker to prefer mold or lld over the default
linker, since the system linker is usually ld.bfd which is very slow.
(Also, for some reason mold produces smaller binaries than lld).
This adds support for the 'go install' case, where we link against the
system LLVM (Homebrew, Linux distro version, etc). This does not have an
effect on `make`, which still uses LLVM 19 for now.
The main reason for doing this is because newer distros like Fedora 42
and Homebrew have switched to LLVM 20, so switching to this newer
version helps those people. (I'm one of those people, I'm on Fedora 42).
There are two small changes for WebAssembly included:
* nontrapping-fptoint was enabled in the wasmbuiltin library used for
wasm-unknown. This matches wasm-unknown which already had this
enabled, so it doesn't add any new instructions.
* bulk-memory was enabled in wasi-libc. This was previously enabled in
all the other WebAssembly targets (wasm, wasip1, wasip2) so this
does't add any new instructions. I think it was also enabled in the
wasi-libc build before
https://github.com/tinygo-org/tinygo/pull/4820 but I don't know for
sure.
Instead of relying on a build when TinyGo is being built, do it like all
other libraries when it is needed.
This brings a few benefits:
* No more running `make wasi-libc` on the command line as a special
case for WebAssembly. The generic `git submodule update --init` step
is now enough for wasi-libc.
* It becomes much easier to customize the build per system. For
example: include/exclude malloc as needed, disable/enable bulk
memory operations per target, etc.
This adds support for the well-known Boehm GC. It's significantly faster
than our own naive GC and could be used as an alternative on bigger
systems.
In the future, this GC might also be supported on WebAssembly with some
extra work. Right now it's Linux only (though Windows/MacOS shouldn't be
too difficult to add).
Run a range of tests in CI, to make sure browser wasm and baremetal
don't regress too badly.
I have intentionally filtered out tests, so that newly added tests to
TEST_PACKAGES_FAST will be added here as well (and can be excluded if
needed).
deadprogram
Pavel Burgr
Jake Bailey
Victor Costa
Ayke van Laethem
Elias Naur
luoliwoshang