mirror of https://github.com/boa-dev/boa.git
Tree:
5125da0008
add-vhs-ci
benchmarks
control-flow-graph
expect-lints
feature/node_span
feature/snapshot
features
gh-readonly-queue/main/pr-2877-b0ddf5eed00a53281d67fc7d846233fc0d99ce9c
gh-readonly-queue/main/pr-3144-8e48cec73fae708420b9af88813d4870243c491a
main
nan-boxing
optimization/static-shapes
real_conformance
reduce-environment-allocations
refactor/interner
refactor/register-vm
releases/0.17
releases/0.19
semver_checks
tco
utility-crate
wasm-debugger
nightly
v0.10
v0.11
v0.12
v0.13
v0.14
v0.15
v0.16
v0.17
v0.17.1
v0.17.2
v0.17.3
v0.18
v0.19
v0.19.1
v0.2.0
v0.2.1
v0.3.0
v0.4.0
v0.5.0
v0.5.1
v0.6.0
v0.7.0
v0.8.0
v0.9.0
${ noResults }
4 Commits (5125da00082d73b28526b9b4822e7d69f356c90f)
Author | SHA1 | Message | Date |
---|---|---|---|
raskad | a5e8111fa2 |
Restructure lints in multiple crates (#2447)
This Pull Request restructures the lint deny/warn/allow lists in almost all crates. `boa_engine` will be done in a follow up PR as the changes there are pretty extensive. |
2 years ago |
Kevin | 98e6dd36cb |
Boa Gc implementation draft (#2394)
<!---
Thank you for contributing to Boa! Please fill out the template below, and remove or add any
information as you feel necessary.
--->
Not sure if anyone else may be working on something more substantial/in-depth, but I thought I'd post this. 😄
The basic rundown is that this is more of an untested (and in some ways naïve) draft than anything else. It builds rather heavily on `rust-gc`, and tries to keep plenty of the core aspects so as to not break anything too much, and also to minimize overarching changes were it to actually be merged at some point.
This implementation does add ~~a generational divide (although a little unoptimized) to the heap,~~ a GcAlloc/Collector struct with methods, and an ephemeron implementation that allows for the WeakPair and WeakGc pointers.
|
2 years ago |
dependabot[bot] | 96d4ed8d70 |
Bump syn from 1.0.102 to 1.0.103 (#2358)
Bumps [syn](https://github.com/dtolnay/syn) from 1.0.102 to 1.0.103. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/syn/releases">syn's releases</a>.</em></p> <blockquote> <h2>1.0.103</h2> <ul> <li>Implement <code>PartialOrd</code> for <code>Cursor</code> (<a href="https://github-redirect.dependabot.com/dtolnay/syn/issues/1236">#1236</a>, <a href="https://github-redirect.dependabot.com/dtolnay/syn/issues/1237">#1237</a>, thanks <a href="https://github.com/CAD97"><code>@CAD97</code></a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
2 years ago |
José Julián Espina | df70302194 |
First prototype for new `JsString` using UTF-16 (#1659)
I think it's time to address the elephant in the room. This Pull Request will (hopefully!) solve part of #736. This is a complete rewrite of `JsString`, but instead of storing `u8` bytes it stores `u16` words. The `encode!` macro (renamed to `utf16!` for simplicity) from the `const-utf16` crate allows us to create UTF-16 encoded arrays at compilation time. `JsString` implements `Deref<Target=[u16]>` to unlock the slice methods and possibly make some manipulations easier. However, we would need to create our own library of utilities for `JsString`. |
2 years ago |