..Default::default()

Like I used in the other PR, this helps just ensure we have less "challenges" maintaining code when there are potential changes to the protocol in the future.

Not in general, I think. Restricting the type of a v8::FunctionTemplate receiver through a v8::Signature gives a modicum of runtime safety but that's not compile-time safety, of course.

Is there a way to do this in rusty_v8? I've looked at both the docs and the source, and I couldn't find any way to create a v8::Signature, so I'm wondering if there's something I missed or it just isn't implemented yet.

We should set a label here, but the lsp-types crate doesn't contain it at the moment. I opened PR https://github.com/gluon-lang/lsp-types/pull/207 to add it, but obviously it will take a way to work through, so we should update this when the dependencies get updated. Maybe add a TODO for now (or create a tracking issue)?

        document_symbols.push(lsp::DocumentSymbol {
          name: self.text.clone(),
          kind: self.kind.clone().into(),
          range: span.to_range(line_index),
          selection_range: selection_span.to_range(line_index),
          tags,
          children,
          ..Default::default()
        })

I believe this should allow you to remove the #[allow(deprecated)].

Could you please provide a more complete replication.

Did this same code work in previous versions of Deno?

deno: 1.9.0

responding to http request from onmessage (response from worker) in the main thread

getting this error:

error: Uncaught (in promise) BadResource: Bad resource ID
          numBytesWritten = await this.writer.write(data);
                            ^
    at unwrapOpResult (deno:core/core.js:100:13)
    at async write (deno:runtime/js/12_io.js:107:12)
    at async BufWriter.write (https://deno.land/std@0.93.0/io/bufio.ts:501:29)
    at async writeResponse (https://deno.land/std@0.93.0/http/_io.ts:275:15)
    at async ServerRequest.respond (https://deno.land/std@0.93.0/http/server.ts:87:7)

This commit aligns Headers to spec. It also removes the now unused 03_dom_iterable.js file. We now pass all relevant Headers WPT. We do not implement any sort of header filtering, as we are a server side runtime.

This is likely not the most efficient implementation of Headers yet. It is however spec compliant. Once all the APIs in the HTTP hot loop are correct we can start optimizing them. It is likely that this reduces bench throughput temporarily.

Adds example code for how to use deno with .wasm files.

Not sure if something else is preffered over readAll() from io/util.ts, but it's what worked for me.

Adds the possibility to use environment variables on the Deno path in settings.

Resolves #377

The error comes from the following sample code:

// A.ts
import { b1 } from "./B.ts";

export const a1 = () => {
    console.log(b1);
}

export const a2 = () => {
    "a2";
}

//B.ts
import { a2 } from "./A.ts";

export const b1 = "b1";

export const b2 = () => {
    console.log(a2);
}

// main.ts
import { a1 } from "./A.ts"

a1();

When running deno run main.ts on either Linux or MacOS it outputs b1 which is expected, however on Windows it outputs the following error:

error: Cannot resolve module "file:///.../A" from "file:///.../main.ts".
    at file:///.../main.ts:1:0

Seems like the import on main is causing problems, that is because A.ts and B.ts are importing modules from each other however it's not the same modules, so it can't be a circular dependency. That error though Cannot resolve module seems to occur when the runtime gives up on importing the module; from my research, it can occur in cases of circular dependency. Maybe on the Windows environment, it thinks it's a circular dependency, not entirely sure though.

deno_build.txt

cargo install deno produces the attached output, here is the error:

   Compiling deno_runtime v0.11.0
error[E0004]: non-exhaustive patterns: `MaxFilesWatch` not covered
  --> /Users/geordi/.cargo/registry/src/github.com-1ecc6299db9ec823/deno_runtime-0.11.0/errors.rs:75:9
   |
75 |   match error.kind {
   |         ^^^^^^^^^^ pattern `MaxFilesWatch` not covered
   | 
  ::: /Users/geordi/.cargo/registry/src/github.com-1ecc6299db9ec823/notify-5.0.0-pre.7/src/error.rs:34:5
   |
34 |     MaxFilesWatch,
   |     ------------- not covered
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
   = note: the matched value is of type `notify::ErrorKind`

error: aborting due to previous error

@cztomsik Plugins are broken in 1.9 due to the substantial op-layer changes. There are efforts to improve plugins for 1.10, migrating them over to the new ops, access to ResourceTable/OpState, etc...

it's here https://github.com/cztomsik/graffiti but I think it's because ABI changed so I will check that first (I copied "headers" to the project so I don't need to depend on rusty_v8 https://github.com/cztomsik/graffiti/blob/30a9aa89f01a3ac121be024feef238c115e92704/libgraffiti/src/bindings/deno.rs#L88)

@lucacasonato Really? I had quite the opposite thinking, I believe that it should be easier for you to refactor the internals, knowing that all types passed to the internal code will be receiving the correct types, at least.

But if you disagree, I doubt that this PR will be of much use, considering that a correct implementation of the fetch spec expects all input to be normalised and casted to WebIDL types. Maybe we'd be better off if you just copy & pasted (most of) the converters over, and we close this PR?

deno eval $code does not emit stack trace item for throw statement itself.

@kdy1 Stack traces show the construction site of the error, so it should point to the new.

node -e $code emits stack proper stack trace

What do you mean by this? Is there a way I can check that behaviour?

Right now, deno install produces a shim like the following:

% generated by deno install %
@deno.exe "run" "--allow-read" "--allow-write" "--allow-net" "--allow-env" "--allow-run" "--no-check" "https://deno.land/x/deploy/deployctl.ts" %*

This is incorrect because the deno command might not be deno.exe (as is the case on my system where it runs from deno.cmd or deno.ps1 via bvm).

This fix does the following:

1. It uses the first deno executable on the PATH, so it works the same way as executing the deno command.
2. It supports more than just a deno.exe executable being on the path.

I tried fixing it, but I'm not sure if it's issue of swc. node -e $code emits stack proper stack trace, so it seems like the source map is correct, but deno eval $code does not emit stack trace item for throw statement itself.

Test code is at https://github.com/swc-project/swc/blob/67a853285d7e37204d61aae8e9b130fcf1686e79/tests/source_map.rs

I'm getting this with native plugin after last upgrade

Not sure what you mean, please provide reproduction.

I'm getting this with native plugin after last upgrade

Right now, deno install produces a shim like the following:

% generated by deno install %
@deno.exe "run" "--allow-read" "--allow-write" "--allow-net" "--allow-env" "--allow-run" "--no-check" "https://deno.land/x/deploy/deployctl.ts" %*

This is incorrect because the deno command might not be deno.exe (as is the case on my system where it runs from deno.cmd via bvm).

This fix does the following:

1. It uses the first deno executable on the PATH, so it works the same way as executing the deno command.
2. It supports more than just a deno.exe executable being on the path.

The problem causing the "operation canceled" error has been resolved by 9e38473. However, the canary build seems to be failing... :thinking: :cry:

Done!

The bug the PR is fixing doesn't seem to be a bug on windows as per https://github.com/denoland/deno/runs/2373907680?check_suite_focus=true#step:28:2087 hence not running the test on windows.

Stumbled upon in https://jakedeichert.com/blog/reducing-rust-incremental-compilation-times-on-macos-by-70-percent/

It lowers incremental debug build from about 1m10s to 30s on my machine.

This PR adds url parsing benches in op_crates/url named url_ops, which allow for scoped & fast iteration on url parsing performance (since the builds take ~30x less time to build than full deno bins).

This does a decent job at showcasing bench_util (#10223) outside of op_baseline and how in ~30 lines you can put together benches to track performance that also generate clean profiles when flamebench'd.

Sample output

test bench_url_parse ... bench:   5,822,207 ns/iter (+/- 231,035)

Note: this follows the same convention of 1000 real iters per bench iter as op_baseline, so just right shift 3 digits when reading these results.

As a sanity check we can see that these benches ~match the output of deno_common:

url_parse:           	n = 50000, dt = 0.290s, r = 172414/s, t = 5799ns/op

Currently, Deno.connect only supports IPC for unix (using unstable transport: "unix"). There should be named pipes support too, which would allow IPC on Windows (as NodeJS' net mode does).

Please move this test to cli/tests/workers/test.ts