Support TypeScript experimental decorators on abstract class fields (#3684)
With this release, you can now use TypeScript experimental decorators on abstract class fields. This was silently compiled incorrectly in esbuild 0.19.7 and below, and was an error from esbuild 0.19.8 to esbuild 0.20.1. Code such as the following should now work correctly:
// Original code
const log = (x: any, y: string) => console.log(y)
abstract class Foo { @log abstract foo: string }
new class extends Foo { foo = '' }
// Old output (with --loader=ts --tsconfig-raw={"compilerOptions":{"experimentalDecorators":true}})
const log = (x, y) => console.log(y);
class Foo {
}
new class extends Foo {
foo = "";
}();
// New output (with --loader=ts --tsconfig-raw={"compilerOptions":{"experimentalDecorators":true}})
const log = (x, y) => console.log(y);
class Foo {
}
__decorateClass([
log
], Foo.prototype, "foo", 2);
new class extends Foo {
foo = "";
}();
JSON loader now preserves __proto__ properties (#3700)
Copying JSON source code into a JavaScript file will change its meaning if a JSON object contains the __proto__ key. A literal __proto__ property in a JavaScript object literal sets the prototype of the object instead of adding a property named __proto__, while a literal __proto__ property in a JSON object literal just adds a property named __proto__. With this release, esbuild will now work around this problem by converting JSON to JavaScript with a computed property key in this case:
// Original code
import data from 'data:application/json,{"__proto__":{"fail":true}}'
if (Object.getPrototypeOf(data)?.fail) throw 'fail'
// Old output (with --bundle)
(() => {
// <data:application/json,{"proto":{"fail":true}}>
var json_proto_fail_true_default = { proto: { fail: true } };
// entry.js
if (Object.getPrototypeOf(json_proto_fail_true_default)?.fail)
throw "fail";
})();
Support TypeScript experimental decorators on abstract class fields (#3684)
With this release, you can now use TypeScript experimental decorators on abstract class fields. This was silently compiled incorrectly in esbuild 0.19.7 and below, and was an error from esbuild 0.19.8 to esbuild 0.20.1. Code such as the following should now work correctly:
// Original code
const log = (x: any, y: string) => console.log(y)
abstract class Foo { @log abstract foo: string }
new class extends Foo { foo = '' }
// Old output (with --loader=ts --tsconfig-raw={"compilerOptions":{"experimentalDecorators":true}})
const log = (x, y) => console.log(y);
class Foo {
}
new class extends Foo {
foo = "";
}();
// New output (with --loader=ts --tsconfig-raw={"compilerOptions":{"experimentalDecorators":true}})
const log = (x, y) => console.log(y);
class Foo {
}
__decorateClass([
log
], Foo.prototype, "foo", 2);
new class extends Foo {
foo = "";
}();
JSON loader now preserves __proto__ properties (#3700)
Copying JSON source code into a JavaScript file will change its meaning if a JSON object contains the __proto__ key. A literal __proto__ property in a JavaScript object literal sets the prototype of the object instead of adding a property named __proto__, while a literal __proto__ property in a JSON object literal just adds a property named __proto__. With this release, esbuild will now work around this problem by converting JSON to JavaScript with a computed property key in this case:
// Original code
import data from 'data:application/json,{"__proto__":{"fail":true}}'
if (Object.getPrototypeOf(data)?.fail) throw 'fail'
// Old output (with --bundle)
(() => {
// <data:application/json,{"proto":{"fail":true}}>
var json_proto_fail_true_default = { proto: { fail: true } };
// entry.js
if (Object.getPrototypeOf(json_proto_fail_true_default)?.fail)
throw "fail";
})();
Welcome to wazero 1.7: the release that upgrades like a minor, but feels like a major!
It's finally time for the long-awaited, final release of our brand new optimizing compiler. This is such a big deal that we are celebrating it at [Wasm I/O 2024][wasmio] with another round of wonderful lightning talks from wazero users [like we did in 2023][wazero1]. In fact, even this release is being tagged during the event! Stay tuned on our usual channels to see the recording:
Follow the [#wazero hashtag on Twitter][twitter]
Join the [#wazero channel on the Gophers Slack][gophers]
wazero optimizes machine code compiled from wasm
Translating Wasm bytecode into machine code can take multiple forms. An optimizing compiler performs multiple nontrivial transformations on the input code, ultimately producing more efficient ("optimized") code.
In 1.7 we replaced our internal wasm compiler with an optimizing one. This means it is a drop-in: you don’t need to do anything to use it. If interested in compiler design, please read [the docs][wazevo-docs], contributed by @evacchi.
As for performance improvements, we have come to expect a run-time boost ranging from 10% to even 60%, with 30-40% being the average. Notably:
@ncruces' fork of [coremark][coremark] shows an improved score of 15265 vs 9591, i.e. about +60% on arm64 (Apple M1 Pro)
[mercari/grpc-federation][mercari] improvements between 4-10% on their Wasm extensions to the [Common Extension Language][cel]
[kubernetes-sigs/kube-scheduler-wasm-extension][k8s-sched] sees an average of >40% decrease on schedule lifecycle overhead
@achille-roussel [contributed some numbers][achille-slack] on the Go standard library (GOOS=wasip1) showing at least 30% improvements on the syscall, compress/flate (gzip) and encoding/json packages, with peaks of 60% (especially in data throughput).
While a major improvement, we decided against calling this version 2.0. If we did, we would cause library dependency lockups due to go imports needing a ‘/v2’. We take backwards compatibility seriously, so couldn’t do that to you!
As usual, @mathetake owns the lionshare of the contributions, with @evacchi helping along the way, especially on the new amd64 backend. Notably, @achille-roussel also contributed a performance improvement to the compiler (#2026) and @ncruces helped in many ways with testing and verifying the implementation, validating (among other things) against his library [go-sqlite3][go-sqlite3].
Note: an optimizing compiler does more work, so it takes longer. Production use of wazero should always compile wasm during initialization to avoid slowing down function runtime.
Experimental: Wasm Threads Spec
The Wasm Threads spec introduces instructions to explicitly share memory between modules, and new operations for atomic memory access. Compilers may use this feature for concurrent threads of execution. For instance @anuraaga’s [Go ports of protoc plugins][protoc] needed atomic instruction support to compile to Wasm.
1.7 concludes a long journey started with @anuraaga's first PR #1899 and continued with @mathetake occasionally tag-teaming, especially to support in the new compiler; @ncruces assisted with reviewing.
You can enable Wasm Threads support by setting the corresponding flag:
// Threads support must be enabled explicitly in addition to standard V2 features.
cfg := wazero.NewRuntimeConfig().
WithCoreFeatures(api.CoreFeaturesV2 | experimental.CoreFeaturesThreads)
The Snapshot/Restore experimental feature saves the state of a wasm function and restores it later. This feature has been contributed by @anuraaga to implement exception handling in [wasilibs/go-pgquery][go-pgquery]
You can enable snapshot/restore by setting the context flag:
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
- `@dependabot ignore minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
- `@dependabot ignore ` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore ` will remove all of the ignore conditions of the specified dependency
- `@dependabot unignore ` will remove the ignore condition of the specified dependency and ignore conditions
Bumps the all group with 3 updates: github.com/evanw/esbuild, github.com/sashabaranov/go-openai and github.com/tetratelabs/wazero.
Updates
github.com/evanw/esbuild
from 0.20.1 to 0.20.2Release notes
Sourced from github.com/evanw/esbuild's releases.
... (truncated)
Changelog
Sourced from github.com/evanw/esbuild's changelog.
... (truncated)
Commits
617edda
publish 0.20.2 to npm4780075
fix #3700: json loader preserves__proto__
keys30bed2d
better errors for invalid js decorator syntax300eeb7
ts: allow non-null assertions in js decorators4d997d9
fix #3698: yarn pnp edge case withtsconfig.json
cf42954
resolver: improve some debug loggingb0765ae
fix some lintsdfa6206
fix some comments (closes #3683)ae5cc17
fix #3684:abstract
experimental decoratorsc809af0
fix #2388: allow consuming types without dom types (#3679)Updates
github.com/sashabaranov/go-openai
from 1.20.3 to 1.20.4Release notes
Sourced from github.com/sashabaranov/go-openai's releases.
Commits
0925563
Fix broken implementation AssistantModify implementation (#685)Updates
github.com/tetratelabs/wazero
from 1.6.0 to 1.7.0Release notes
Sourced from github.com/tetratelabs/wazero's releases.
... (truncated)
Commits
253c034
ci: removes unnecessary matrix.include (#2155)2bbe81a
wazevo(frontend): allocation free initializeCurrentBlockKnownBounds (#2154)1b3f80b
ci: always use the same command to upload artifacts (#2153)b4f47d9
fuzz: adds --no-trace-compares flag by default (#2152)291fdf8
wazevo: fixes accidental heap allocation in VarLengthPool.Allocate (#2151)0255886
regalloc: fast check for preferred in findOrSpillAllocatable (#2150)5760022
validation: handles edge case of unexpected else (#2148)a05f23b
wasi: uses the shared compilation cache in tests (#2149)9f56676
testing: removes remaining gotip usage (#2147)c4532da
testing: pass N, P into Run of hammer (#2146)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show