git.delta.rocks / jrsonnet / refs/commits / 772afa0049b2

* feat: properly implement math ops for bigint

* feat: remove bigint x string and bigint x num ops

every op now requires explicit conversion

* fix: remove dead code

* Support fields aliases

* Improve codegen

Chomped string blocks

* native implementation of std.splitLimitR

* style: fix formatting

---------

* build: bump Rust version and update dependencies

* chore: resolve all reported Clippy issues

* build: use the correct Toolchain version

* ci: update GitHub Workflows to use valid actions

* ci: add permissions to `clippy_check`

* chore(GH-160): bump dependencies and disable `thread_local_initializer_can_be_made_const` lint

* chore(GH-160): try fixing `thread_local_initializer_can_be_made_const`

* fix(GH-160): `serialized-stdlib` feature

* ci(GH-160): fix `Test Suite`

* fix(GH-160): resolve `insta` deprecation

* ci(GH-160): add formatting check job

* ci(GH-160): reorganize jobs

* style(GH-160): fix formatting

* build(GH-160): fix `#[cfg(never)]`

* build(GH-160): `#[allow(dead_code)]` on `FinishedRanger::end_token`

* build(GH-160): allow more dead code

* test(GH-160): fix `golden.rs`

* ci: update sjsonnet for benchmark

* doc: scratch benchmarks results

* feat: another Rust jsonnet implementation appears!

Ref: https://github.com/google/jsonnet/pull/1156

* chore: use jdk21-headless for sjsonnet

* chore: fix go-jsonnet benchmarking

* chore: increase default max-stack for rsjsonnet

* chore: update sjsonnet to v0.4.10

* chore: update skipped benchmarks list

* chore: rerun benchmarks

Stack depth measurement works differently in jrsonnet, yet old value was
chosen based on golang, and when there was not much in regard to stack
size optimization in jrsonnet.

Jsonnet spec defines special behavior for `super.field` and
`field in super` expressions, while in jrsonnet it is implemented by
standalone-super concept, with optimizations in case of `super.field`.

However, standalone-super is conflicting with `field in super` behavior,
so special handling is needed for this expression.

It was kept to be a consumer of jrsonnet-parser, but wasn't really
working, in future a proper LSP implementation will be developed.