This commit stabilizes "Deno.serve()", which becomes the
preferred way to create HTTP servers in Deno.
Documentation was adjusted for each overload of "Deno.serve()"
API and the API always binds to "127.0.0.1:8000" by default.
This PR changes Web IDL interfaces to be declared with `var` instead of
`class`, so that accessing them via `globalThis` does not raise type
errors.
Closes #13390.
Fixes #19687 by adding a rejection handler to the write inside the
setTimeout. There is a small window where the promise is actually not
awaited and may reject without a handler.
Support strings (&str, String, and Cow) in the argument position and String in the return position. Avoids
copies where possible, though this is not always something we can do.
Currently the resolution for extension sources is different depending on
whether `include_js_files_for_snapshotting`
is enabled. If sources are embedded it uses `include_str!()` which is
module-relative. If sources are read at runtime paths are joined to
`CARGO_MANIFEST_DIR` and are package-relative. This makes them both
package-relative.
Fixes `cargo run -p deno_runtime --example extension_with_esm --features
include_js_files_for_snapshotting`.
Implementation of generics for `#[op2]`, along with some refactoring to
improve the ergonomics of ops with generics parameters:
- The ops have generics on the struct rather than the associated
methods, which allows us to trait-ify ops (impossible when they are on
the methods)
- The decl() method can become a trait-associated const field which
unlocks future optimizations
Callers of ops need to switch from:
`op_net_connect_tcp::call::<TestPermission>(conn_state, ip_addr)` to
`op_net_connect_tcp::<TestPermission>::call(conn_state, ip_addr)`.
This is a reproduction and fix for a very obscure bug where the Deno
runtime locks up we end up polling an empty JoinSet and attempt to
resolve ops after-the-fact. There's a small footgun in the JoinSet API
where polling it while empty returns Ready(None), which means that it
never holds on to the waker. This means that if we aren't testing for
this particular return value and don't stash the waker ourselves for a
future async op to eventually queue, we can end up losing the waker
entirely and the op wakes up, notifies tokio, which notifies the
JoinSet, which then has nobody to notify 😢.
Co-authored-by: Luca Casonato <hello@lcas.dev>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes the WPT tests that test w/invalid codes. Also explicitly ignoring
some h2 tests to hopefully prevent flakes.
The previous changes to WebSocketStream introduced a bug where the close
errors were not made available if the `pull` method was re-entrant.
This is a fix for issue #19644, concerning the `parseCssColor` function
in the file `ext/console/01_console.js`. Changes made on lines
2756-2758. To sum it up:
> The internal `parseCssColor` function currently parses 3/4-digit hex
colors incorrectly. For example, it parses the string `#FFFFFF` as
`[255, 255, 255]` (as expected), but returns `[240, 240, 240]` for
`#FFF`, when it should return the same triplet as the former.
While it's not going to cause a fatal runtime error, it did bug me
enough to fix it real quick.
Attempts to fix the thread_safe_callback flakiness. It's unclear what
the flake is about, the exit code is apparently `C0000005` or
`ACCESS_VIOLATION`, pointing to an issue with memory access. My only
guess is that maybe dropping the `Option<extern "C" fn ()>` is somehow
checking the validity of the function pointer and since the function has
been dropped, the pointer is no longer valid and sometimes points to
memory that should not be accessed.
So now the will explicitly drop the functions before they get
deallocated. If this doesn't fix the flake then something beyond my
understanding is wrong.
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.
…nclusion" (#19519)"
This reverts commit 28a4f3d0f5.
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
```
