foster/denoland-deno
1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-26 16:09:27 -05:00
Code Issues Packages 1 Wiki Activity
10675 commits 128 branches 353 tags 306 MiB
Commit graph

42 commits

Author SHA1 Message Date
Bartek Iwańczuk
942fb5e038
chore: upgrade deno_core (#22124) 
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
 2024-01-26 14:04:07 -05:00
Bartek Iwańczuk
9951506506
fix(node): remove deprecation warnings (#22120) 
Closes https://github.com/denoland/deno/issues/22116
 2024-01-26 00:36:03 +01:00
Kenta Moriuchi
515a34b4de
refactor: use core.ensureFastOps() (#21888) 2024-01-10 15:37:25 -07:00
cions
881a62869d
fix: android support (#19437) 
<!--
Before submitting a PR, please read https://deno.com/manual/contributing

1. Give the PR a descriptive title.

  Examples of good title:
    - fix(std/http): Fix race condition in server
    - docs(console): Update docstrings
    - feat(doc): Handle nested reexports

  Examples of bad title:
    - fix #7123
    - update docs
    - fix bugs

2. Ensure there is a related issue and it is referenced in the PR text.
3. Ensure there are tests that cover the changes.
4. Ensure `cargo test` passes.
5. Ensure `./tools/format.js` passes without changing files.
6. Ensure `./tools/lint.js` passes.
7. Open as a draft PR if your work is still in progress. The CI won't
run
   all steps, but you can add '[ci]' to a commit message to force it to.
8. If you would like to run the benchmarks on the CI, add the 'ci-bench'
label.
-->

---------

Signed-off-by: Matt Mastracci <matthew@mastracci.com>
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
 2024-01-10 06:04:14 -07:00
Kenta Moriuchi
e7e25db24f
chore: update deno_lint for CI (#21802) 2024-01-05 15:03:06 +00:00
Kenta Moriuchi
b2cd254c35
fix: strict type check for cross realms (#21669) 
Deno v1.39 introduces `vm.runInNewContext`. This may cause problems when
using `Object.prototype.isPrototypeOf` to check built-in types.

```js
import vm from "node:vm";

const err = new Error();
const crossErr = vm.runInNewContext(`new Error()`);

console.assert( !(crossErr instanceof Error) );
console.assert( Object.getPrototypeOf(err) !== Object.getPrototypeOf(crossErr) );
```

This PR changes to check using internal slots solves them.

---

current: 

```
> import vm from "node:vm";
undefined
> vm.runInNewContext(`new Error("message")`)
Error {}
> vm.runInNewContext(`new Date("2018-12-10T02:26:59.002Z")`)
Date {}
```

this PR:

```
> import vm from "node:vm";
undefined
> vm.runInNewContext(`new Error("message")`)
Error: message
    at <anonymous>:1:1
> vm.runInNewContext(`new Date("2018-12-10T02:26:59.002Z")`)
2018-12-10T02:26:59.002Z
```

---------

Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
 2024-01-04 09:42:38 +05:30
Divy Srivastava
ad65440092
fix(ext/node): UdpSocket ref and unref (#21777) 2024-01-04 08:51:39 +05:30
David Sherret
7e72f3af61
chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
Bartek Iwańczuk
f85d65e066
chore: update deno_core to 0.240.0 (#21726) 2023-12-28 19:30:07 +00:00
Kenta Moriuchi
68241234fa
fix(console): inspect for {Set,Map}Iterator and Weak{Set,Map} (#21554) 2023-12-19 15:05:49 +09:00
Bartek Iwańczuk
c1fc7b2cd5
refactor: pull 'core', 'internals', 'primordials' from ES module (#21462) 
This commit refactors how we access "core", "internals" and
"primordials" objects coming from `deno_core`, in our internal JavaScript code.

Instead of capturing them from "globalThis.__bootstrap" namespace, we
import them from recently added "ext:core/mod.js" file.
 2023-12-07 14:21:01 +01:00
Leo Kettmeir
32c041c8d7
Reland "fix(ext/console): fix inspecting iterators error. (#20720)" (#21370) 2023-11-28 16:07:48 +01:00
Bartek Iwańczuk
9b9ec44db7
Revert "fix(ext/console): fix inspecting iterators error. (#20720)" (#21191) 
This reverts commit 0209f7b469.

Reverting because it causes failures on `main`:
https://github.com/denoland/deno/pull/20720#issuecomment-1809166755
 2023-11-13 22:16:23 +00:00
Chen Su
0209f7b469
fix(ext/console): fix inspecting iterators error. (#20720) 
Fixes #19776 and #20676.
 2023-11-13 20:13:20 +01:00
Divy Srivastava
09204107d8
fix: implement node:tty (#20892) 
Fixes #21012
Closes https://github.com/denoland/deno/issues/20855
Fixes https://github.com/denoland/deno/issues/20890
Fixes https://github.com/denoland/deno/issues/20611
Fixes https://github.com/denoland/deno/issues/20336
Fixes `create-svelte` from https://github.com/denoland/deno/issues/17248

Fixes more reports here:
- https://github.com/denoland/deno/issues/6529#issuecomment-1432690559
- https://github.com/denoland/deno/issues/6529#issuecomment-1522059006
- https://github.com/denoland/deno/issues/6529#issuecomment-1695803570
 2023-10-30 15:53:08 +00:00
Divy Srivastava
ab3c9d41e4
fix(ext/node): implement uv.errname (#20785) 
Fixes https://github.com/denoland/deno/issues/20617
 2023-10-05 18:27:20 +00:00
Chen Su
507f24c474
fix(ext/node): fix TypeError in Buffer.from with base64url encoding. (#20705) 
For the following example, if I set the encoding to `base64url`, it'll
throw an unexpected TypeError:

```ts
import { Buffer } from "node:buffer";

Buffer.from("IntcImhlbGxvXCI6XCJoZGQvZStpXCJ9Ig", "base64url").toString();

// error: Uncaught TypeError: src.subarray is not a function
// const buf = Buffer.from(
//                    ^
//     at blitBuffer (ext:deno_node/internal/buffer.mjs:1779:15)
//     at Uint8Array.base64urlWrite (ext:deno_node/internal/buffer.mjs:691:10)
//     at Object.write (ext:deno_node/internal/buffer.mjs:2195:11)
//     at Uint8Array.write (ext:deno_node/internal/buffer.mjs:794:14)
//     at fromString (ext:deno_node/internal/buffer.mjs:214:22)
//     at _from (ext:deno_node/internal/buffer.mjs:119:12)
//     at Function.from (ext:deno_node/internal/buffer.mjs:157:10)
//     at file:///Users/foodieats/temp/buffer1.ts:3:20
```

The error caused by `base64urlWrite` function, it should call
`forgivingBase64UrlDecode` not `forgivingBase64UrlEncode`

Also fixed #20563 .
 2023-09-27 07:54:19 -06:00
Bartek Iwańczuk
aaff69db3f
perf(node/net): optimize socket reads for 'npm:ws' package (#20449) 
Fixes performance regression introduced by
https://github.com/denoland/deno/pull/20223 and
https://github.com/denoland/deno/pull/20314. It's enough to have one
"shared" buffer per socket
and no locking mechanism is required.
 2023-09-11 20:38:57 +02:00
Aapo Alasuutari
9d6584c16f
perf(ext/node): Optimise Buffer string operations (#20158) 
Extracted from https://github.com/denoland/deno/pull/17815

Optimise Buffer's string operations, most significantly when dealing
with ASCII and UTF-16. Base64 and HEX encodings are affected to much
lesser degrees.

## Performance

### String length 15
With very small strings we're at break-even or sometimes even lose a tad
bit of performance from creating a `DataView` that ends up not paying
for itself.

**This PR:**
```
benchmark                                                     time (avg)        iter/s             (min … max)       p75       p99      p995
-------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string                                       1.15 µs/iter     871,388.6   (728.78 ns … 1.56 µs)   1.23 µs   1.56 µs   1.56 µs
Buffer.from base64 string                                      1.63 µs/iter     612,790.9     (1.31 µs … 1.96 µs)   1.77 µs   1.96 µs   1.96 µs
Buffer.from utf16 string                                       1.41 µs/iter     707,396.3   (915.24 ns … 1.93 µs)   1.61 µs   1.93 µs   1.93 µs
Buffer.from hex string                                         1.87 µs/iter     535,357.9     (1.56 µs … 2.19 µs)      2 µs   2.19 µs   2.19 µs
Buffer.toString ascii string                                 154.58 ns/iter   6,469,162.8    (149.69 ns … 198 ns) 154.51 ns 182.89 ns 191.91 ns
Buffer.toString base64 string                                161.65 ns/iter   6,186,189.6 (150.91 ns … 181.15 ns) 165.18 ns 171.87 ns 174.94 ns
Buffer.toString utf16 string                                 292.74 ns/iter   3,415,959.8 (285.43 ns … 312.47 ns) 295.25 ns 310.47 ns 312.47 ns
Buffer.toString hex string                                    89.61 ns/iter  11,159,315.6  (81.09 ns … 123.77 ns)  91.09 ns 113.62 ns 119.28 ns
```

**Main:**
```
benchmark                                                     time (avg)        iter/s             (min … max)       p75       p99      p995
-------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string                                       1.26 µs/iter     794,875.8     (1.07 µs … 1.46 µs)   1.31 µs   1.46 µs   1.46 µs
Buffer.from base64 string                                      1.65 µs/iter     607,853.3     (1.38 µs … 2.01 µs)   1.69 µs   2.01 µs   2.01 µs
Buffer.from utf16 string                                       1.34 µs/iter     744,894.6     (1.09 µs … 1.55 µs)   1.45 µs   1.55 µs   1.55 µs
Buffer.from hex string                                         2.01 µs/iter     496,345.8      (1.54 µs … 2.6 µs)   2.26 µs    2.6 µs    2.6 µs
Buffer.toString ascii string                                 150.16 ns/iter   6,659,630.5 (144.99 ns … 166.68 ns)  152.4 ns 157.26 ns 159.14 ns
Buffer.toString base64 string                                164.73 ns/iter   6,070,692.0 (158.77 ns … 185.63 ns) 168.48 ns 175.74 ns 176.68 ns
Buffer.toString utf16 string                                 150.61 ns/iter   6,639,864.0  (148.2 ns … 168.29 ns) 150.93 ns 157.21 ns 168.15 ns
Buffer.toString hex string                                    94.21 ns/iter  10,614,972.9   (86.21 ns … 98.75 ns)  95.43 ns  97.99 ns  98.21 ns
```

### String length 1500
With moderate lengths we already see great upsides for `Buffer.from()`
with ASCII and UTF-16.

**This PR:**
```
benchmark                                                     time (avg)        iter/s             (min … max)       p75       p99      p995
-------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string                                       5.79 µs/iter     172,562.6     (4.72 µs … 4.71 ms)   5.04 µs   10.3 µs  11.67 µs
Buffer.from base64 string                                      5.08 µs/iter     196,678.9     (4.97 µs … 5.76 µs)   5.08 µs   5.76 µs   5.76 µs
Buffer.from utf16 string                                       9.68 µs/iter     103,316.5     (7.14 µs … 3.44 ms)  10.32 µs  13.42 µs  15.21 µs
Buffer.from hex string                                         53.7 µs/iter      18,620.2     (49.37 µs … 2.2 ms)  54.74 µs   72.2 µs  81.07 µs
Buffer.toString ascii string                                   6.63 µs/iter     150,761.3     (5.59 µs … 1.11 ms)   6.08 µs  15.68 µs  24.77 µs
Buffer.toString base64 string                                460.57 ns/iter   2,171,224.4 (448.33 ns … 511.73 ns) 465.05 ns 495.54 ns 511.73 ns
Buffer.toString utf16 string                                   6.52 µs/iter     153,287.0     (6.47 µs … 6.66 µs)   6.53 µs   6.66 µs   6.66 µs
Buffer.toString hex string                                     3.68 µs/iter     271,965.4     (3.64 µs … 3.82 µs)   3.68 µs   3.82 µs   3.82 µs
```

**Main:**
```
benchmark                                                     time (avg)        iter/s             (min … max)       p75       p99      p995
-------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string                                      11.46 µs/iter      87,298.1    (8.53 µs … 834.1 µs)   9.61 µs  83.31 µs   87.3 µs
Buffer.from base64 string                                       5.4 µs/iter     185,027.8     (5.07 µs … 7.49 µs)   5.44 µs   7.49 µs   7.49 µs
Buffer.from utf16 string                                       20.3 µs/iter      49,270.8  (13.55 µs … 649.11 µs)   18.8 µs 113.93 µs 125.17 µs
Buffer.from hex string                                        52.03 µs/iter      19,218.9    (48.74 µs … 2.59 ms)  52.84 µs  67.05 µs  73.56 µs
Buffer.toString ascii string                                   6.46 µs/iter     154,822.5     (6.32 µs … 6.69 µs)   6.52 µs   6.69 µs   6.69 µs
Buffer.toString base64 string                                440.19 ns/iter   2,271,764.6    (427 ns … 490.77 ns) 444.74 ns 484.64 ns 490.77 ns
Buffer.toString utf16 string                                   6.89 µs/iter     145,106.7     (6.81 µs … 7.24 µs)   6.91 µs   7.24 µs   7.24 µs
Buffer.toString hex string                                     3.66 µs/iter     273,456.5      (3.6 µs … 4.02 µs)   3.64 µs   4.02 µs   4.02 µs
```

### String length 2^20
With massive lengths we the difference in ASCII and UTF-16 parsing
performance is enormous.

**This PR:**
```
benchmark                                                           time (avg)        iter/s             (min … max)       p75       p99      p995
-------------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string                                              4.1 ms/iter         243.7     (2.64 ms … 6.74 ms)   4.43 ms   6.26 ms   6.74 ms
Buffer.from base64 string                                            3.74 ms/iter         267.6     (2.91 ms … 4.92 ms)   3.96 ms   4.31 ms   4.92 ms
Buffer.from utf16 string                                             7.72 ms/iter         129.5    (5.91 ms … 11.03 ms)   7.97 ms  11.03 ms  11.03 ms
Buffer.from hex string                                              35.72 ms/iter          28.0   (34.71 ms … 38.42 ms)  35.93 ms  38.42 ms  38.42 ms
Buffer.toString ascii string                                        78.92 ms/iter          12.7   (42.72 ms … 94.13 ms)  91.64 ms  94.13 ms  94.13 ms
Buffer.toString base64 string                                      833.62 µs/iter       1,199.6   (638.05 µs … 5.97 ms) 826.86 µs   2.45 ms   2.48 ms
Buffer.toString utf16 string                                        79.35 ms/iter          12.6    (69.72 ms … 88.9 ms)  86.66 ms   88.9 ms   88.9 ms
Buffer.toString hex string                                          31.04 ms/iter          32.2      (4.3 ms … 46.9 ms)  37.21 ms   46.9 ms   46.9 ms
```

**Main:**
```
benchmark                                                           time (avg)        iter/s             (min … max)       p75       p99      p995
-------------------------------------------------------------------------------------------------------------------- -----------------------------
Buffer.from ascii string                                            18.66 ms/iter          53.6   (15.61 ms … 23.26 ms)  20.62 ms  23.26 ms  23.26 ms
Buffer.from base64 string                                             4.7 ms/iter         212.9     (2.94 ms … 9.07 ms)   4.65 ms   9.06 ms   9.07 ms
Buffer.from utf16 string                                            33.49 ms/iter          29.9   (31.24 ms … 35.67 ms)  34.08 ms  35.67 ms  35.67 ms
Buffer.from hex string                                              39.38 ms/iter          25.4   (38.66 ms … 42.36 ms)  39.58 ms  42.36 ms  42.36 ms
Buffer.toString ascii string                                        77.68 ms/iter          12.9   (67.46 ms … 95.68 ms)  84.71 ms  95.68 ms  95.68 ms
Buffer.toString base64 string                                      825.53 µs/iter       1,211.3   (655.38 µs … 6.69 ms) 816.62 µs   3.07 ms   3.13 ms
Buffer.toString utf16 string                                        76.54 ms/iter          13.1    (66.9 ms … 85.26 ms)  83.63 ms  85.26 ms  85.26 ms
Buffer.toString hex string                                          38.56 ms/iter          25.9   (33.83 ms … 46.56 ms)  45.33 ms  46.56 ms  46.56 ms
```
 2023-09-07 14:41:16 -06:00
David Sherret
3fc19dab47
feat: support import attributes (#20342) 2023-09-07 09:09:16 -04:00
Matt Mastracci
7adaf613bf
fix(ext/node): shared global buffer unlock correctness fix (#20314) 
The fix for #20188 was not entirely correct -- we were unlocking the
global buffer incorrectly. This PR introduces a lock state that ensures
we only unlock a lock we have taken out.
 2023-08-28 15:28:39 -06:00
Matt Mastracci
c37b9655b6
fix(ext/node): simultaneous reads can leak into each other (#20223) 
Reported in #20188

This was caused by re-use of a global buffer `BUF` during simultaneous
async reads.
 2023-08-22 14:45:10 +00:00
Divy Srivastava
33dc5d2622
fix(node): implement TLSSocket._start (#20120) 
Closes https://github.com/denoland/deno/issues/19983
Closes https://github.com/denoland/deno/issues/18303
Closes https://github.com/denoland/deno/issues/16681
Closes https://github.com/denoland/deno/issues/19978
 2023-08-11 11:57:41 +00:00
Divy Srivastava
51b3534b3d
fix(ext/node): check if resource can be used with write_vectored (#19868) 
Fixes https://github.com/denoland/deno/issues/19766 
Fixes https://github.com/denoland/deno/issues/19846
 2023-07-18 23:34:26 +02:00
Divy Srivastava
e4870d84be
perf(ext/node): native vectored write for server streams (#19752) 
```
# main
$ ./load_test 10 0.0.0.0 8080 0 0
Using message size of 20 bytes
Running benchmark now...
Msg/sec: 106182.250000
Msg/sec: 110279.750000
^C

# this PR
$ ./load_test 10 0.0.0.0 8080 0 0
Using message size of 20 bytes
Running benchmark now...
Msg/sec: 131632.250000
Msg/sec: 134754.250000
^C
```
 2023-07-07 22:17:08 +05:30
Divy Srivastava
57fae55d82
perf(ext/node): optimize net streams (#19678) 
~4.5x improvement in `npm:ws` echo benchmark:

```
$ ./load_test 10 0.0.0.0 8080 0 0
Using message size of 20 bytes
Running benchmark now...
Msg/sec: 101083.750000
Msg/sec: 103606.000000
^C

$ ./load_test 10 0.0.0.0 8080 0 0
Using message size of 20 bytes
Running benchmark now...
Msg/sec: 24906.750000
Msg/sec: 28478.000000
^C
```
 2023-07-05 22:45:10 +05:30
Bartek Iwańczuk
01f0d03ae8
refactor: rename built-in node modules from ext:deno_node/ to node: (#19680) 
Closes https://github.com/denoland/deno/issues/19510
 2023-07-02 20:19:30 +02:00
Bartek Iwańczuk
f372688f22
fix: lint on main branch (#19622) 2023-06-27 17:35:19 +09:00
Kenta Moriuchi
e16b74d792
chore(ext/node): disable prefer-primordials on a per-file basis (#19553) 2023-06-27 15:18:22 +09:00
Martin Fischer
801b9ec62d
chore: fix typos (#19572) 2023-06-26 09:10:27 -04:00
VlkrS
ea97af312f
feat: Adaptations to support OpenBSD port (#19153) 2023-06-12 13:14:27 +03:00
Bartek Iwańczuk
a11681a9b0
refactor(node): use internal io and fs APIs (#19267) 2023-05-26 16:18:27 +02:00
Yoshiya Hinosawa
f520284081
refactor(ext/node): remove polyfills/_core.ts (#18766) 2023-04-20 13:24:28 +09:00
Bartek Iwańczuk
e5b2815b39
Reland "refactor: remove Deno[Deno.internal].nodeUnstable namespace" (#18475) 
This reverts commit 357bcfcf79.
 2023-03-28 14:44:22 +02:00
Bartek Iwańczuk
357bcfcf79
Revert "refactor: remove Deno[Deno.internal].nodeUnstable namespace (… (#18458) 
…#18449)"

This reverts commit d1a9c4cd7c.

Appears this made CI very flaky on macOS, but I can't repeat it locally
yet
 2023-03-27 14:25:17 +00:00
Bartek Iwańczuk
d1a9c4cd7c
refactor: remove Deno[Deno.internal].nodeUnstable namespace (#18449) 
Since we can preserve ops in the snapshot these days, we no longer
need to have "Deno[Deno.internal].nodeUnstable" namespace.

Instead, various built-in Node.js modules can use appropriate APIs
directly.
 2023-03-27 02:15:08 +02:00
Bartek Iwańczuk
72fe9bb470
refactor: rename InternalModuleLoader to ExtModuleLoader, use ext: scheme for snapshotted modules (#18041) 
This commit renames "deno_core::InternalModuleLoader" to
"ExtModuleLoader" and changes the specifiers used by the 
modules loaded from this loader to "ext:".

"internal:" scheme was really ambiguous and it's more characters than
"ext:", which should result in slightly smaller snapshot size.

Closes https://github.com/denoland/deno/issues/18020
 2023-03-08 12:44:54 +01:00
Divy Srivastava
c9c782940e
chore(ext/node): cleanup empty internal_bindings (#18032) 2023-03-05 10:53:42 -04:00
Bartek Iwańczuk
b40086fd7d
refactor(core): include_js_files! 'dir' option doesn't change specifiers (#18019) 
This commit changes "include_js_files!" macro from "deno_core"
in a way that "dir" option doesn't cause specifiers to be rewritten 
to include it.

Example:
```
include_js_files! {
  dir "js",
  "hello.js",
}
```

The above definition required embedders to use:
`import ... from "internal:<ext_name>/js/hello.js"`. 
But with this change, the "js" directory in which the files are stored
is an implementation detail, which for embedders results in: 
`import ... from "internal:<ext_name>/hello.js"`.

The directory the files are stored in, is an implementation detail and 
in some cases might result in a significant size difference for the 
snapshot. As an example, in "deno_node" extension, we store the 
source code in "polyfills" directory; which resulted in each specifier 
to look like "internal:deno_node/polyfills/<module_name>", but with 
this change it's "internal:deno_node/<module_name>". 

Given that "deno_node" has over 100 files, many of them having 
several import specifiers to the same extension, this change removes
10 characters from each import specifier.
 2023-03-05 02:31:38 +00:00
Yoshiya Hinosawa
3187e4e909
fix(ext/node): util.types.isSharedArrayBuffer (#17836) 2023-02-26 11:23:53 +09:00
Divy Srivastava
0aeb8bc759
perf(ext/node): move winerror binding to rust (#17792) 
16873 lines of JS removed from the snapshot.
 2023-02-16 19:19:32 +05:30
Bartek Iwańczuk
d47147fb6a
feat(ext/node): embed std/node into the snapshot (#17724) 
This commit moves "deno_std/node" in "ext/node" crate. The code is
transpiled and snapshotted during the build process.

During the first pass a minimal amount of work was done to create the
snapshot, a lot of code in "ext/node" depends on presence of "Deno"
global. This code will be gradually fixed in the follow up PRs to migrate
it to import relevant APIs from "internal:" modules.

Currently the code from snapshot is not used in any way, and all
Node/npm compatibility still uses code from 
"https://deno.land/std/node" (or from the location specified by 
"DENO_NODE_COMPAT_URL"). This will also be handled in a follow 
up PRs.

---------

Co-authored-by: crowlkats <crowlkats@toaxl.com>
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
 2023-02-14 17:38:45 +01:00