* Make space for tree sitter
* Add the tree sitter wasm file
* Very naive tree-sitter syntax highlighting for html, with a layer breaker
* Update tree when content changes
* WIP for making abstract tokens class
* Handle theme changes
* Replace entire text model value with parse callback
* Perf improvements
* Add tree-sitter-typescript
* Add typescript + better initial parsing
* Refactor into tree parsing service and fix flaw in parse callback
* Remove things that aren't the parser service
* Add yielding
* Remove changes that aren't required for PR
* Remove more file changes
* Reduce yield to 50 ms
* Fix incremental parsing
* Try update node-abi
* Revert "Try update node-abi"
This reverts commit df28801e31.
* Update text buffer chunk api
* fix build
* Remove tree-sitter dependency
* Adopt new, as yet unpublished, `@vscode/tree-sitter-wasm` package
* Use published `@vscode/tree-sitter-wasm` package
* Break `TreeSitterTree` and `TreeSitterParserService` into better pieces
and:
- document the order of editor changes
- use service injection where `TextModel` is constructed
* Fix tests
* Remove unneeded import
* Fix missing tree-sitter-wasm in web and remote
* Make package.jsons match
* Add @vscode/tree-sitter-wasm to web loader config
* Try using importAMDNodeModule
* PR feedback
* Add race condition test for changing language while loading language
* Use same timeout
* Queue content changes
* Remove override dispose
* Move queue into TreeSitterTree
---------
Co-authored-by: Peng Lyu <penn.lv@gmail.com>
* Make space for tree sitter
* Add the tree sitter wasm file
* Very naive tree-sitter syntax highlighting for html, with a layer breaker
* Update tree when content changes
* WIP for making abstract tokens class
* Handle theme changes
* Replace entire text model value with parse callback
* Perf improvements
* Add tree-sitter-typescript
* Add typescript + better initial parsing
* Refactor into tree parsing service and fix flaw in parse callback
* Remove things that aren't the parser service
* Add yielding
* Remove changes that aren't required for PR
* Remove more file changes
* Reduce yield to 50 ms
* Fix incremental parsing
* Try update node-abi
* Revert "Try update node-abi"
This reverts commit df28801e31.
* Update text buffer chunk api
* fix build
* Remove tree-sitter dependency
* Adopt new, as yet unpublished, `@vscode/tree-sitter-wasm` package
* Use published `@vscode/tree-sitter-wasm` package
* Break `TreeSitterTree` and `TreeSitterParserService` into better pieces
and:
- document the order of editor changes
- use service injection where `TextModel` is constructed
* Fix tests
* Remove unneeded import
* Fix missing tree-sitter-wasm in web and remote
* Make package.jsons match
* Add @vscode/tree-sitter-wasm to web loader config
* Try using importAMDNodeModule
* PR feedback
* Add race condition test for changing language while loading language
* Use same timeout
* Queue content changes
* Remove override dispose
* Move queue into TreeSitterTree
---------
Co-authored-by: Peng Lyu <penn.lv@gmail.com>
* don't dimiss inline chat content widget when already having typed something
https://github.com/microsoft/vscode-copilot/issues/6067
* extract `TextOnlyMenuEntryActionViewItem` for reuse
* remove unused variables
* * show chat input below request/response pairs
* setting for text-only buttons
* more dynamic buttons
* always show the first request, don't repopulate input with last message
* keep progress bar hidden, rely on "Generating..."
* no more special background color
* add `minimal` renderer style for chat renderings
* tweak font-size for details when render mode is minimal
* stable scroll position for inline chat, don't push down the lines chat is editing but push the inline chat upwards
* more buttons more compact, tweak labels
* * add missing service dependency
* repopulate input for some unit test
* allow output from `InteractiveChatController` suite
* add `ListenerRefusalError` and `ListenerLeakError` which get logged when listener thresholds are exceeded.
The `stack` property of these errors will point towards the most frequent listener and how often it is used. If that's a high number there is a leak (same listener is added over and over again), if that's a low number there might be a conceptual flaw that an emitter is simply too prominent.
* rightfully don't use Error.captureStackTrace (v8/nodejs only)
- Som more tweaks to our own runner scripts to allow asking for the
generated coverage formats.
- Add actions alongside debug/run for executing coverage profiles
- Finish with displaying function coverage stats in Coverage view,
allow changing its sort order.
Fixes#200529Fixes#199380
- Allow coverage bar color thresholds to be configurable as the Java
folks requested.
- Update some of our scripts for integration into
the selfhost test runner.
- Initial parts of showing function coverage in the Test Coverage view.
(Still a work in progress, more tomorrow)
* snippet completions should also check with the completion model
this will allow to return "more" from the snippet completion item provider and rely on the completions model to do some filtering
* when debugging tests allow to use console.log
* fix https://github.com/microsoft/vscode/issues/191070
This adds an `assertHeap` function that can be used in tests. It
takes a heap snapshot, and asserts the state of classes in memory. This
works in Node and the Electron sandbox, but is a no-op in the browser.
Snapshots are process asynchronously and will report failures at the end
of the suite.
This method should be used sparingly (e.g. once at the end of a suite to
ensure nothing leaked before), as gathering a heap snapshot is fairly
slow, at least until V8 11.5.130 (https://v8.dev/blog/speeding-up-v8-heap-snapshots).
When used, the function will ensure the test has a minimum timeout
duration of 20s to avoid immediate failures.
It takes options containing a mapping of class names, and assertion functions
to run on the number of retained instances of that class. For example:
```ts
assertSnapshot({
classes: {
ShouldNeverLeak: count => assert.strictEqual(count, 0),
SomeSingleton: count => assert(count <= 1),
}
});
```
Closes https://github.com/microsoft/vscode/issues/191920
Second attempt at this, which should work. Stop trying to use
exposeFunction, which seems to work poorly on macOS webkit in CI, and
just run a server with HTTP endpoints to do the "RPC."
Reuses Alex's "yaserver" module that we were already using for other
tests. Uses a secure random prefix for security in each run.
Should fix the issue that @roblourens and @Yoyokrazy were hitting with snapshot tests on macOS WebKit in CI. Not pretty, but I'd rather do this than spend a bunch of time chasing down something that certainly seems to be a browser issue.
* eng: add support for snapshot tests
This adds Jest-like support for snapshot testing.
Developers can do something like:
```js
await assertSnapshot(myComplexObject)
```
The first time this is run, the snapshot expectation file is written
to a `__snapshots__` directory beside the test file. Subsequent runs
will compare the object to the snapshot, and fail if it doesn't match.
You can see an example of this in the test for snapshots themselves!
After a successful run, any unused snapshots are cleaned up. On a failed
run, a gitignored `.actual` snapshot file is created beside the
snapshot for easy processing and inspection.
Shortly I will do some integration with the selfhost test extension to
allow developers to easily update snapshots from the vscode UI.
For #189680
cc @ulugbekna @hediet
* fix async stacktraces getting clobbered
* random fixes
* comment out leak detector, for now
* add option to snapshot file extension
* Add more logging and perf markers around resolving the connection token and the socket factory
* set `exposeFunction` earlier
* bla windows
* also expose function for unit tests beofre opening
Co-authored-by: Benjamin Pasero <benjamin.pasero@microsoft.com>
* ipc: use vql for uint types
On the plane I was reverse-engineering ipc.ts to implement it in Rust
and see if we could have a "service mode" for the CLI that we could
interact with like any other vscode process.
In doing so, I noticed that numbers in the protocol--which are used at
least twice in the message header and ID--were encoded as JSON. I was
curious what benefits we'd get from encoding them as variable-length
integers instead.
It makes the message shorter, as expected. Encode/decode time are very,
very slightly lower. I'm not sure it's worth the extra complexity, but
I have included it here for your consideration.
* fixup tests
