[pull] main from denoland:main #370
Open
+536,925
−326,458
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
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.
This commit changes `Deno.lint.runPlugin` to throw in non-`deno test` subcommand, instead of returning `undefined`.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
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>
…28089) 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 ```
This is the release commit being forwarded back to main for 2.1.10 --------- Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Untested because I am not on a windows machine atm. Closes #28092
So you can edit (e.g.) 00_typescript.js and not have to recompile during dev
This PR adds a part of the `SourceCode` API in eslint (see https://eslint.org/docs/latest/extend/custom-rules#applying-fixes) . It's used to get the text of the current node, etc.
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 #28070
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.
This PR aligns the `RuleContext` of JS plugins with ESLint. --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
- 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
To reduce binary size impact --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Added this so that we only export exports from `Deno.lint`. Required to pass DefinitelyTyped's linting.
A vector with fixes was always created, even if there were no applicable fixes.
This PR reduces the flakiness of the case `req.body.getReader().read() throws the error with reasonable error message`. The case tries to cause BadResource error by premature disconnection from the client, but it sometimes completes the request when the reading of tcp data happens quickly. This PR tries to prevent that scenario by adding some delays when reading & writing http messages.
This is the release commit being forwarded back to main for 2.2.7 Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com> Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
Co-authored-by: XYCode <xycode-xyc@outlook.com>
Reduces some repeat hashmap lookups by exposing the `LspScopedResolver`.
Fixes #28757. We need to retain the napi symbols in the binary. `strip` with no flags on macos strips all symbols out of the binary (including global symbols). Only strip out the local and debug symbols from the binary, retaining the global symbols (which include the napi ones)
Co-authored-by: dsherret <dsherret@users.noreply.github.com>
Probably caused by copy-pasting from the canary upload job.
…e FileHandle class (#28700) Co-authored-by: Nikolay Karadzhov <nkaradzhov89@gmail.com> Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
…ter than latest version (#28787) Signed-off-by: David Sherret <dsherret@users.noreply.github.com>
It's gotten too flaky.
Fixes #27264. Fixes #28161. Currently the new lockfile version is gated behind an unstable flag (`--unstable-lockfile-v5`) until the next minor release, where it will become the default. The main motivation here is that it improves startup performance when using the global cache or `--node-modules-dir=auto`. In a create-next-app project, running an empty file: ``` ❯ hyperfine --warmup 25 -N --setup "rm -f deno.lock" "deno run --node-modules-dir=auto -A empty.js" "deno-this-pr run --node-modules-dir=auto -A empty.js" "deno-this-pr run --node-modules-dir=auto --unstable-lockfile-v5 empty.js" "deno run --node-modules-dir=manual -A empty.js" "deno-this-pr run --node-modules-dir=manual -A empty.js" Benchmark 1: deno run --node-modules-dir=auto -A empty.js Time (mean ± σ): 247.6 ms ± 1.7 ms [User: 228.7 ms, System: 19.0 ms] Range (min … max): 245.5 ms … 251.5 ms 12 runs Benchmark 2: deno-this-pr run --node-modules-dir=auto -A empty.js Time (mean ± σ): 169.8 ms ± 1.0 ms [User: 152.9 ms, System: 17.9 ms] Range (min … max): 168.9 ms … 172.5 ms 17 runs Benchmark 3: deno-this-pr run --node-modules-dir=auto --unstable-lockfile-v5 empty.js Time (mean ± σ): 16.2 ms ± 0.7 ms [User: 12.3 ms, System: 5.7 ms] Range (min … max): 15.2 ms … 19.2 ms 185 runs Benchmark 4: deno run --node-modules-dir=manual -A empty.js Time (mean ± σ): 16.2 ms ± 0.8 ms [User: 11.6 ms, System: 5.5 ms] Range (min … max): 14.9 ms … 19.7 ms 187 runs Benchmark 5: deno-this-pr run --node-modules-dir=manual -A empty.js Time (mean ± σ): 16.0 ms ± 0.9 ms [User: 12.0 ms, System: 5.5 ms] Range (min … max): 14.8 ms … 22.3 ms 190 runs Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options. Summary deno-this-pr run --node-modules-dir=manual -A empty.js ran 1.01 ± 0.08 times faster than deno run --node-modules-dir=manual -A empty.js 1.01 ± 0.07 times faster than deno-this-pr run --node-modules-dir=auto --unstable-lockfile-v5 empty.js 10.64 ± 0.60 times faster than deno-this-pr run --node-modules-dir=auto -A empty.js 15.51 ± 0.88 times faster than deno run --node-modules-dir=auto -A empty.js ``` When using the new lockfile version, this leads to a 15.5x faster startup time compared to the current deno version. Install times benefit as well, though to a lesser degree. `deno install` on a create-next-app project, with everything cached (just setting up node_modules from scratch): ``` ❯ hyperfine --warmup 5 -N --prepare "rm -rf node_modules" --setup "rm -rf deno.lock" "deno i" "deno-this-pr i" "deno-this-pr i --unstable-lockfile-v5" Benchmark 1: deno i Time (mean ± σ): 464.4 ms ± 8.8 ms [User: 227.7 ms, System: 217.3 ms] Range (min … max): 452.6 ms … 478.3 ms 10 runs Benchmark 2: deno-this-pr i Time (mean ± σ): 368.8 ms ± 22.0 ms [User: 150.8 ms, System: 198.1 ms] Range (min … max): 344.8 ms … 397.6 ms 10 runs Benchmark 3: deno-this-pr i --unstable-lockfile-v5 Time (mean ± σ): 211.9 ms ± 17.1 ms [User: 7.1 ms, System: 177.2 ms] Range (min … max): 191.3 ms … 233.4 ms 10 runs Summary deno-this-pr i --unstable-lockfile-v5 ran 1.74 ± 0.17 times faster than deno-this-pr i 2.19 ± 0.18 times faster than deno i ``` With lockfile v5, a 2.19x faster install time compared to the current deno.
Fixes #28767 Don't love the `RefCell`, but don't really see a (safe) way around it.
Fixes #26400. Correctly handle multi-icon icos in `deno compile --icon`. Ref denoland/sui@bf318ea ## Explanation Icons in PE are very sensitive to resource table ordering. Here's what works: <img width=320 src=https://github.com/user-attachments/assets/8f3e5a18-5f00-42d6-a366-16b6194c711c></img> We can't use `editpe`'s builtin `set_icon` because it lays out `Icon` and `Icon Group` together before/after the `RCData`. Instead, we need a custom implementation that places RCData between the icon entries. This means we defer `Icon Group` to always happen during `PortableExecutable::build`. After the fix: <img width=440 src=https://github.com/user-attachments/assets/73a9b347-64c2-41e1-a314-918231ba7276></img>
Noticed that the `.parent` type was missing for AST nodes for our JS lint API. Whenever possible I've only specified the limited possibilities of parent types, but when it's too complex I defaulted to just `Node`.
These both were >20KB. Also added `clippy::large_futures` to `lint.js` so we catch this
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )