Currently fast ops will always check for the alignment of a TypedArray
when getting a slice out of them. A match is then done to ensure that
some slice was received and if not a fallback will be requested.
For Uint8Arrays (and WasmMemory which is equivalent to a Uint8Array) the
alignment will always be okay. Rust probably optimises this away for the
most part (since the Uint8Array check is `x % 1 != 0`), but what it
cannot optimise away is the fast ops path's request for fallback options
parameter.
The extra parameter's cost is likely negligible but V8 will need to
check if a fallback was requested and prepare the fallback call just in
case it was. In the future the lack of a fallback may also enable V8 to
much better optimise the result handling.
For V8 created buffers, it seems like all buffers are actually always
guaranteed to be properly aligned: All buffers seem to always be created
8-byte aligned, and creating a 32 bit array or 64 bit array with a
non-aligned offset from an ArrayBuffer is not allowed. Unfortunately,
Deno FFI cannot give the same guarantees, and it is actually possible
for eg. 32 bit arrays to be created unaligned using it. These arrays
work fine (at least on Linux) so it seems like this is not illegal, it
just means that we cannot remove the alignment checking for 32 bit
arrays.
The commit derives Eq, PartialEq, and Debug traits for the
`ResolutionKind` enum to make it possible for external
implementors to assert ResolutionKind.
This commit changes handling of config file to enable
specifying "imports" and "scopes" objects effectively making
the configuration file an import map.
"imports" and "scopes" take precedence over "importMap" configuration,
but have lower priority than "--importmap" CLI flag.
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
Co-authored-by: David Sherret <dsherret@gmail.com>
This commit adds sync versions of async APIs to "Deno.permissions"
namespace.
Following APIs were added:
- "Deno.permissions.querySync"
- "Deno.permissions.requestSync"
- "Deno.permissions.revokeSync"
Allows to change behavior of `deno fmt` to use "ASI" setting for
semicolons instead of always prefering them, this is done
by "--options-semi=asi" flag or `"semi": "asi"` setting
in the config file.
This commit removes "Deno.core" namespace. It is strictly private API
that has no stability guarantees, we were supposed to remove it long time ago.
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
This change prints a link to the release notes to `deno upgrade` output
and its variations.
Release notes aren't printed for commands relating to canary versions.
Closes #16350.
<!--
Before submitting a PR, please read http://deno.land/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.
-->
This patch makes `NativeType` to `libffi::middle::Type` conversion
failliable and w.t disallows struct with empty fields. libffi does not
handle "empty" struct because they don't exist in C (or Rust).
Fixes #17481
- changes module id to be usize & 0 based instead of 1 based
- merges `ids_by_handle` & `handles_by_id` to be a single `handles`
vector
- removes `next_module_id`, as vector is used
- turns `info` into a vector
This commit adds support for snapshotting ES modules. This is done by
adding an ability to serialize and deserialize a "ModuleMap" and attach
it
to the snapshot, using "add_context_data" API.
This has been tested with 400 modules and seems to not have a limit on
the number of modules that might be snapshotted.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
