Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
This is also a performance improvement because declaration file hashes
don't need to be stored in the lockfile.
Closes #19444
|
|
The copyright checker was allowing files with code above the copyright
line in a few places, mainly as a result of IDEs ordering imports
improperly.
This makes the check more robust, and adds a whitelist of valid lines
that may appear before the copyright line.
|
|
|
|
(#19611)
…nclusion" (#19519)"
This reverts commit 28a4f3d0f5383695b1d49ccdc8b0f799a715b2c2.
This change causes failures when used outside Deno repo:
```
============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.
Platform: linux x86_64
Version: 1.34.3+b37b286
Args: ["/opt/hostedtoolcache/deno/0.0.0-b37b286f7fa68d5656f7c180f6127bdc38cf2cf5/x64/deno", "test", "--doc", "--unstable", "--allow-all", "--coverage=./cov"]
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failed to read "/home/runner/work/deno/deno/core/00_primordials.js"
Caused by:
No such file or directory (os error 2)', core/runtime/jsruntime.rs:699:8
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
|
|
|
|
|
|
The following code:
```rust
use deno_core::op;
#[op]
fn ops_serde_v8(value: serde_v8::Value) {
//
}
fn main() {
//
}
```
...with the following `Cargo.toml`:
```toml
[package]
name = "playground"
version = "0.1.0"
edition = "2021"
[dependencies]
deno_core = "0.191.0"
serde_v8 = "0.102.0"
```
...will not compile with the error:
```
error[E0433]: failed to resolve: use of undeclared crate or module `v8`
--> src/main.rs:3:1
|
3 | #[op]
| ^^^^^ use of undeclared crate or module `v8`
|
= note: this error originates in the attribute macro `op` (in Nightly builds, run with -Z macro-backtrace for more info)
```
This PR is fixing the above issue by properly quoting
`deno_core::v8::Value` instead of `v8::Value`.
|
|
Implements `Result` in fast-calls. Note that the approach here is
slightly different. Rather than store the last result in the `OpState`,
we put it into the `OpCtx` which saves us a lookup and lock in the error
case. We do not have to lock this field as it's guaranteed only one
runtime and thread can ever access it.
The fastcall path for many ops can avoid doing a great deal of work,
even for `Result` return values. In the previous iteration of `ops`, all
`Result`-returning functions would fetch and lock the `OpState`,
regardless of whether it was used or not.
|
|
This test is very flaky.
|
|
Relands #19463. This time the `ExtensionFileSourceCode` enum is
preserved, so this effectively just splits feature
`include_js_for_snapshotting` into `exclude_js_sources` and
`runtime_js_sources`, adds a `force_include_js_sources` option on
`extension!()`, and unifies `ext::Init_ops_and_esm()` and
`ext::init_ops()` into `ext::init()`.
|
|
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
This is a new op system that will eventually replace `#[op]`.
Features
- More maintainable, generally less-coupled code
- More modern Rust proc-macro libraries
- Enforces correct `fast` labelling for fast ops, allowing for visual
scanning of fast ops
- Explicit marking of `#[string]`, `#[serde]` and `#[smi]` parameters.
This first version of op2 supports integer and Option<integer>
parameters only, and allows us to start working on converting ops and
adding features.
|
|
The WHATWG DOM specification has corrected the spelling of "slotable" to
"slottable".[1] This commit aligns our implementation accordingly.
[1]: https://github.com/whatwg/dom/pull/845
|
|
|
|
|
|
Fixes #19568
Values are not coerced to the desired type during deserialisation. This
makes serde_v8 stricter.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
This fixes a bug in file metadata parsing logic, which now properly
evaluates boolean fields when forwarding for atime / mtime / birthtime
values.
Ref: https://github.com/denoland/deploy_feedback/issues/409
|
|
`ZeroCopyBuf` was convenient to use, but sometimes it did hide details
that some copies were necessary in certain cases. Also it made it way to easy
for the caller to pass around and convert into different values. This commit
splits `ZeroCopyBuf` into `JsBuffer` (an array buffer coming from V8) and
`ToJsBuffer` (a Rust buffer that will be converted into a V8 array buffer).
As a result some magical conversions were removed (they were never used)
limiting the API surface and preparing for changes in #19534.
|
|
|
|
NpmResolver (#19582)
|
|
|
|
Not used anymore.
|
|
with `napi_define_properties`.
|
|
... not just `Uint8Array`.
This PR aligns behavior with Node.js Node-API implementation.
|
|
|
|
Fixes a bug I noticed when deriving a key based from `ECDH`. Similar
issue is also mentioned in #14693, where they derive a key using
`PBKDF2`
- In the WebCrypto API, `deriveKey()` is equivalent to `deriveBits()`
followed by `importKey()`
- But, `deriveKey()` requires just `deriveKey` in the `usages` of the
`baseKey` parameter. The `deriveBits` usage is not required to be
allowed. This is the uniform behaviour in Node, Chrome and Firefox.
- The impl currently has userland-accessible `SubtleCrypto.deriveKey()`
and `SubtleCrypto.deriveBits()`, as well as an internal `deriveBits()`
(this is the one that accesses the ffi).
- Also, `SubtleCrypto.deriveKey()` checks if `deriveKey` is an allowed
usage and `SubtleCrypto.deriveBits()` checks if `deriveBits` is an
allowed usage, as required.
- However, the impl currently calls the userland accessible
`SubtleCrypto.deriveBits()` in `SubtleCrypto.deriveKey()`, leading to an
error being thrown if the `deriveBits` usage isn't present.
- Fixed this by making it call the internal `deriveBits()`
instead.
|
|
The callback draining code is no longer needed after #19513.
|
|
Closes https://github.com/denoland/deno/issues/19528
|
|
|
|
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
Fixes https://github.com/denoland/deno/issues/17748
Closes #17770
Co-authored-by: Anton Bershanskiy
<bershanskiy@users.noreply.github.com>
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
|
|
Moves the watch setting out of the `Flags` struct and into the
individual subcommands
|
|
|
|
|
|
(#19480)
|
|
Addresses feedback from
https://github.com/denoland/deno/pull/19412#discussion_r1227912676
|
|
|
|
|
|
Closes #19468
|
|
This removes MaybeDone from op resolution. While it would be nice to avoid the box, most of the work for that future task is done here.
|
|
Reverts denoland/deno#19426
|
|
A few easy migrations of module code from the runtime to the module map.
The module map already has a few places where it needs a handle scope,
so we're not coupling it any further with the v8 runtime.
`init_runtime_module_map` is replaced with an option to reduce API
surface of JsRuntime.
`module_resolve_callback` now lives in the `ModuleMap` and we use a
annex data to avoid having to go through the `Rc<RefCell<...>>` stored
in the `JsRuntime`'s isolate.
|
|
Test is in deno_npm.
Closes #19500
|
|
Closes https://github.com/denoland/deno/issues/19348
This changes benchmark from the issue from:
```
deno run -A https://raw.githubusercontent.com/nats-io/nats.deno/deno-transport-changes/examples/bench.js --subject a --payload 3500 --pub --count 650000
pub 7,636 msgs/sec - [85.13 secs] ~ 25.49 MB/sec 85127.8765/85127.8765
```
to:
```
> ./target/release/deno run -A https://raw.githubusercontent.com/nats-io/nats.deno/deno-transport-changes/examples/bench.js --subject a --payload 3500 --pub --count 650000
pub 176,840 msgs/sec - [3.68 secs] ~ 590.27 MB/sec 3675.646833/3675.646833
> ./target/release/deno run -A https://raw.githubusercontent.com/nats-io/nats.deno/deno-transport-changes/examples/bench.js --subject a --payload 3500 --pub --count 650000
pub 174,589 msgs/sec - [3.72 secs] ~ 582.76 MB/sec 3723.01925/3723.01925
```
|