-
Notifications
You must be signed in to change notification settings - Fork 997
Go 1.14 support #1035
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go 1.14 support #1035
Conversation
|
@aykevl this branch is now ready for conflict resolution, please. |
This makes the result consistent across Go versions, by running a regex on the CGo output that wraps all single-line functions in a consistent way. Originally written by Elliott Sales de Andrade and modified by Ayke van Laethem.
It doesn't seem to be used. This commit is somewhat related to this commit: golang/go@6dd70fc Most of the things don't port over nicely.
See commit: golang/go@54e6ba6 Warning: this will drop support for Go 1.13 for WebAssembly targets! I have modified the integration tests to specifically blacklist Go 1.13 instead of whitelisting any other version, to avoid accidentally not testing WebAssembly.
|
Rebased and fixed conflicts. |
|
Tested with this branch and Go 1.14.2 with some of my demos on AVR, SAMD21, SAMD51, and Hi5 boards, and all worked perfectly. I think this is ready for merge. |
|
Great news folks! Now when |
|
Yes that will happen very soon now. |
This is a continuation of #901. I have modified the PR of @QuLogic to include the bits needed to get all tests to run on Go 1.14 and extended it a bit to switch to Go 1.14 entirely.
Note that this PR drops support for WebAssembly on Go 1.13 (at least when you import the syscall/js package) but I think working around that would be difficult. It should definitely be possible to create a workaround (for example, by exporting a function that when called returns the Go minor version) but I'd like to avoid such hacks if possible. Therefore I would propose keeping it as-is for now and only adding a workaround if there is enough demand (which I don't expect).
This will probably conflict with #1014 but the conflicts should be easy to resolve.