Now that ArrayBuffer/ArrayBufferView is a generic Value type, we have to
handle it being passed any value. To do this, thread
FastApiCallbackOptions through the function, and add error raising
logic.
If we run conversion and the value is not valid, we return `isize::MAX`,
and then in cranelift we use this value to know that we should branch to
the error logic.
An example compilation looks like this:
```rust
extern "C" fn print_buffer(ptr: *const u8, len: usize);
```
```clif
function %print_buffer_wrapper(i64, i64, i64, i64) system_v {
sig0 = (i64, i64) system_v
sig1 = (i64) -> i64 system_v
sig2 = (i64) system_v
block0(v0: i64, v1: i64, v2: i64, v3: i64):
v4 = iconst.i64 0x6525_9198_2d00 ; turbocall_ab_contents
v5 = call_indirect sig1, v4(v1)
v6 = iconst.i64 0x7fff_ffff_ffff_ffff
v7 = icmp eq v5, v6
brif v7, block1, block2
block2:
v8 = iconst.i64 0x7558_4c0c_0700 ; sym.ptr
call_indirect sig0, v8(v5, v2)
return
block1 cold:
v9 = iconst.i64 0x6525_9198_2d70 ; turbocall_raise
call_indirect sig2, v9(v3)
return
}
```
Also cleaned up all the `unwrap`s and added some logging.
- upgrade v8 to 13.4
- turbocall conversion for arraybuffers is now much more complex, so use
cranelift
- misc updates for deprecated fns
- v8 default stack size is too small now, causing stack overflow
exceptions in some tests
- add syscall shim to support new syscall in old sysroot
Cache busts the http cache when the lockfile integrity doesn't match
what's in the cache. This will help when someone's lockfile is in line
with the remote server, but their local cache isn't.
Supports `deno task --frozen=false some_task`, which is necessary
because with `"nodeModulesDir": "auto"` or `"global"` (the default with
no package.json) we do an auto-install of npm packages.
Closes https://github.com/denoland/deno/issues/28070
In particular this helps startup of the TSC isolate because
`00_typescript.js` can use the code cache.
Overall, this offsets a fair bit of the hit we took when we removed the
TSC snapshot.
```
❯ hyperfine --warmup 5 -p "rm -rf ~/Library/Caches/deno/check_cache_v2" "./deno-this-pr check main.ts" "./deno-no-snapshot check main.ts" "./deno-with-snapshot check main.ts"
Benchmark 1: ../../deno/target/release-lite/deno check main.ts
Time (mean ± σ): 145.7 ms ± 3.6 ms [User: 347.6 ms, System: 36.9 ms]
Range (min … max): 142.2 ms … 155.9 ms 19 runs
Benchmark 2: ./deno-no-snapshot check main.ts
Time (mean ± σ): 195.4 ms ± 3.3 ms [User: 397.7 ms, System: 34.9 ms]
Range (min … max): 192.1 ms … 206.0 ms 15 runs
Benchmark 3: ./deno-with-snapshot check main.ts
Time (mean ± σ): 109.0 ms ± 2.2 ms [User: 155.9 ms, System: 19.3 ms]
Range (min … max): 106.5 ms … 118.0 ms 26 runs
Summary
./deno-with-snapshot check main.ts ran
1.34 ± 0.04 times faster than ./deno-this-pr check main.ts
1.79 ± 0.05 times faster than ./deno-no-snapshot check main.ts
```
adds tracing and opentelemetry exporting to the LSP.
enable it in `.vscode/settings.json` (or wherever you configure the
LSP), like
```
{
"deno.tracing": true
}
```
which will by default export opentelemetry traces to `localhost:4317`
or
```
{
"deno.tracing": {
// all fields optional
"collector": "openTelemetry" (default) | "logging" (output in lsp log window)
"collectorEndpoint": "http://localhost:4318" (for opentelemetry)
"enable": true | false,
"filter": "info" // defaults to "info", but can be any span filter
}
}
```
---
a full working setup would be
1: Run jaeger (an opentelemetry collector with a nice UI):
```
docker run --rm -p 16686:16686 -p 4317:4317 jaegertracing/jaeger
```
2. Enable in .vscode/settings.json
```
{
"deno.tracing": true
}
```
3. Restart LSP (right now it only will start the opentelemetry exporter
on LSP startup)
3. open `http://localhost:16686` in your browser
---------
Co-authored-by: Nathan Whitaker <nathan@deno.com>
This commit changes the TS host implementation
in the LSP to use the same snapshot as the runtime worker
and web worker use.
This is due to upcoming V8 upgrade that might require
that all isolates in the same process use the exact same
snapshot.
Removes the TSC snapshot to unblock the V8 upgrade (which enables shared
RO heap, and is incompatible with multiple snapshots).
this compresses the sources and declaration files as well, which leads
to a roughly 4.2MB reduction in binary size.
this currently adds about 80ms to deno check times, but code cache isn't
wired up for the extension code (namely `00_typescript.js`) yet
```
❯ hyperfine --warmup 5 -p "rm -rf ~/Library/Caches/deno/check_cache_v2" "../../deno/target/release-lite/deno check main.ts" "deno check main.ts"
Benchmark 1: ../../deno/target/release-lite/deno check main.ts
Time (mean ± σ): 184.2 ms ± 2.2 ms [User: 378.3 ms, System: 48.2 ms]
Range (min … max): 181.5 ms … 189.9 ms 15 runs
Benchmark 2: deno check main.ts
Time (mean ± σ): 107.4 ms ± 1.2 ms [User: 155.3 ms, System: 23.9 ms]
Range (min … max): 105.3 ms … 109.6 ms 26 runs
Summary
deno check main.ts ran
1.72 ± 0.03 times faster than ../../deno/target/release-lite/deno check main.ts
```
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit removes the docs URL for diagnostics coming
from JS plugins. Before, we mistakenly printed
URLs pointing to `docs.deno.com`, even though they did not
exist.
An ability to actually specify a custom URL for plugin rules,
will be added in a follow up PR.
This commit fixes racy condition in lint plugins
that could have caused diagnostics for another
file to be printed for completely unrelated file.
With this change, a oneshot channel is used
to receive diagnostics for a file, which ensures
that the caller will receive diagnostics for itself.
This clears the diagnostics whenever a file is about to run. For
example, what could previously occur is an error and the diagnostics
would be leftover from the previous run.
Noticed that the LSP might panic during serialization when working on a
file with a syntax error.
This PR changes the serialization so that invalid nodes are simply
serialized to the invalid node `0`. The plugin code treats the node with
id `0` as an invalid node and will ignore it during visiting.
I'm not sure how to write a test for the LSP.
This PR fixes deviations in our AST format compared to TSEStree. They
are mostly a leftover for when I first started working on it and based
it off of babel instead.
One of the key changes why the changeset is a bit bigger is that
TSEStree uses `undefined` instead of `null` as the empty value for type
nodes. This is likely influenced by `tsc` which use `undefined`
everywhere. The rest of the nodes use `null` though. It's a little
weird, but for now it might be better to align.
(extracted from https://github.com/denoland/deno/pull/27977)
Not sure what our handling of unstable properties in `deno.json` is.
This PR adds it to the config schema.
---------
Signed-off-by: Marvin Hagemeister <marvinhagemeister50@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit adds an unstable lint plugin API.
Plugins are specified in the `deno.json` file under
`lint.plugins` option like so:
```
{
"lint": {
"plugins": [
"./plugins/my-plugin.ts",
"jsr:@deno/lint-plugin1",
"npm:@deno/lint-plugin2"
]
}
}
```
The API is considered unstable and might be subject
to changes in the future.
Plugin API was modelled after ESLint API for the
most part, but there are no guarantees for compatibility.
The AST format exposed to plugins is closely modelled
after the AST that `typescript-eslint` uses.
Lint plugins use the visitor pattern and can add
diagnostics like so:
```
export default {
name: "lint-plugin",
rules: {
"plugin-rule": {
create(context) {
return {
Identifier(node) {
if (node.name === "a") {
context.report({
node,
message: "should be b",
fix(fixer) {
return fixer.replaceText(node, "_b");
},
});
}
},
};
},
},
},
} satisfies Deno.lint.Plugin;
```
Besides reporting errors (diagnostics) plugins can provide
automatic fixes that use text replacement to apply changes.
---------
Co-authored-by: Marvin Hagemeister <marvin@deno.com>
Co-authored-by: David Sherret <dsherret@gmail.com>
interactively select which packages to upgrade. a future improvement
could be to add a way to select the version as well, though not sure how
valuable that would be.
