| Age | Commit message (Collapse) | Author |
|---|
|
This commit fixes a problem in import map when resolving
specifiers containing "?" or "#".
Due to special handling of Windows specifiers required because
of how "url" crate works, a regression was introduced that percent-encoded
all parts of URL that were not considered "path segments".
Co-authored-by: Andreu Botella <abb@randomunok.com>
|
|
Fixes #11963.
|
|
|
|
Fixes #9750
|
|
|
|
|
|
|
|
|
|
|
|
In the spec, a URL record has an associated "blob URL entry", which for
`blob:` URLs is populated during parsing to contain a reference to the
`Blob` object that backs that object URL. It is this blob URL entry that
the `fetch` API uses to resolve an object URL.
Therefore, since the `Request` constructor parses URL inputs, it will
have an associated blob URL entry which will be used when fetching, even
if the object URL has been revoked since the construction of the
`Request` object. (The `Request` constructor takes the URL as a string
and parses it, so the object URL must be live at the time it is called.)
This PR adds a new `blobFromObjectUrl` JS function (backed by a new
`op_blob_from_object_url` op) that, if the URL is a valid object URL,
returns a new `Blob` object whose parts are references to the same Rust
`BlobPart`s used by the original `Blob` object. It uses this function to
add a new `blobUrlEntry` field to inner requests, which will be `null`
or such a `Blob`, and then uses `Blob.prototype.stream()` as the
response's body. As a result of this, the `blob:` URL resolution from
`op_fetch` is now useless, and has been removed.
|
|
This adds support for the URLPattern API.
The API is added in --unstable only, as it has not yet shipped in any
browser. It is targeted for shipping in Chrome 95.
Spec: https://wicg.github.io/urlpattern/
Co-authored-by: crowlKats < crowlkats@toaxl.com >
|
|
|
|
This commit updated "deno_lint" crate to 0.15.1 and refactors
"cli/tools/lint.rs" to create only a single vector of lint rules,
instead of creating a vector for each linted file.
|
|
|
|
Ref: #11874
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Craig Morten <cmorten@users.noreply.github.com>
|
|
|
|
|
|
|
|
When `worker.terminate()` is called, the spec requires that the
corresponding port message queue is emptied, so no messages can be
received after the call, even if they were sent from the worker before
it was terminated.
The spec doesn't require this of `self.close()`, and since Deno uses
different channels to send messages and to notify that the worker was
closed, messages might still arrive after the worker is known to be
closed, which are currently being dropped. This change fixes that.
The fix involves two parts: one on the JS side and one on the Rust side.
The JS side was using the `#terminated` flag to keep track of whether
the worker is known to be closed, without distinguishing whether further
messages should be dropped or not. This PR changes that flag to an
enum `#state`, which can be one of `"RUNNING"`, `"CLOSED"` or
`"TERMINATED"`.
The Rust side was removing the `WorkerThread` struct from the workers
table when a close control was received, regardless of whether there
were any messages left to read, which made any subsequent calls to
`op_host_recv_message` to return `Ok(None)`, as if there were no more
mesasges. This change instead waits for both a close control and for
the message channel's sender to be closed before the worker thread is
removed from the table.
|
|
|
|
|
|
|
|
|
|
This feeds console output to the reporter and handles silencing there
instead of in the JavaScript code.
|
|
This commit refactors "DenoSubcommand" enum in a way that variants
no longer contain anonymous structures but instead contain
dedicated structures for each subcommand, eg. "DenoSubcommand::Lint"
now contains "LintSubcommand".
|
|
This commit adds support for following flags in deno lint subcommand:
--config - allows to load configuration file and parses "lint" object
--rules-tags=<tags> - allows specifying which set of tagged rules should be run
--rules-include=<rules> - allow specifying which rules should be run
--rules-exclude=<rules> - allow specifying which rules should not be run
|
|
more info (#11905)
|
|
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
|
|
This is the worker counterpart of PR #11062.
|
|
* feat(core): facilitate op-disabling middleware
By providing `void_op_sync()` and `void_op_async() as well as `core/examples/disable_ops.rs`
|
|
Support AES-CTR, AES-CBC, AES-GCM, and AES-KW in
SubtleCrypto#generateKey.
|
|
|
|
(#11879)
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
