- 16 11月, 2019 2 次提交
-
-
由 Matt Bierner 提交于
For #77131
-
由 Alexandru Dima 提交于
-
- 15 11月, 2019 4 次提交
-
-
由 Benjamin Pasero 提交于
-
由 Johannes Rieken 提交于
-
由 Johannes Rieken 提交于
This reverts commit 544b0abf.
-
由 Johannes Rieken 提交于
-
- 14 11月, 2019 2 次提交
-
-
由 Matt Bierner 提交于
Our code currently uses the `IConstructorSignature` types in a two main ways: - As argument types in functions that take a service constructor. - As return types or property types when we expose a service constructor in the API This first usage is not valid with strict function types. The reason is that the `IConstructorSignature` types takes a rest array of `...services: BrandedService[]` , while the concrete constructors you pass in use actual services. With strict function types, you cannot convert the concrete constructor type to an `IConstructorSignature` because this would drop important type information that the implementation needs. As an example ```ts class Foo { constructor(@ILogService service: ILogService) {} } registerFoo(Foo); // The type of `ctor` inlines `IConstructorSignature0` function registerFoo(ctor: { new(....serivces: BrandedService[]): Foo}) { // When registerFoo(Foo) is called, the implementation here would need to know that // ctor needs to be invoked with exactly one `ILogService`. However the type of `IConstructorSignature0` // does not express this. Strict function types therefore disallows this conversion } ``` To fix this, I have converted a few places were we were taking `IConstructorSignature` arguments so that they preserve the full type of the constructor. This fixed over half of our 900 strict function type errors. Unfortunatly I can not figure out a more elegant way to express this besides inlining the types However, even after this change, we still need to figure out how to deal with: - Places in the code where `IConstructorSignature` is exposed as a return type or object property - How to deal with all of our descriptor types (such as `SyncActionDescriptor`)
-
由 Andre Weinand 提交于
-
- 13 11月, 2019 3 次提交
-
-
由 Joao Moreno 提交于
related to #84283
-
由 Matt Bierner 提交于
For #84283
-
由 Benjamin Pasero 提交于
* debt - allow extHostSearch in common * web - implement text search provider * fix text search * Update extensions/vscode-api-tests/src/extension.ts Co-Authored-By: NRob Lourens <roblourens@gmail.com>
-
- 12 11月, 2019 3 次提交
-
-
由 Alex Ross 提交于
Part of #84283
-
由 Benjamin Pasero 提交于
-
由 Matt Bierner 提交于
-
- 11 11月, 2019 8 次提交
-
-
由 Johannes Rieken 提交于
-
由 Johannes Rieken 提交于
-
由 Johannes Rieken 提交于
-
由 Sandeep Somavarapu 提交于
-
由 Johannes Rieken 提交于
-
由 Johannes Rieken 提交于
-
由 Johannes Rieken 提交于
-
由 Johannes Rieken 提交于
-
- 10 11月, 2019 2 次提交
-
-
由 Konstantin Solomatov 提交于
remove dead code
-
由 Konstantin Solomatov 提交于
-
- 09 11月, 2019 3 次提交
- 08 11月, 2019 4 次提交
-
-
由 Johannes Rieken 提交于
-
由 Matt Bierner 提交于
This currently is not connected to any actual actions in the editor
-
由 Matt Bierner 提交于
-
由 Matt Bierner 提交于
-
- 07 11月, 2019 2 次提交
-
-
由 Johannes Rieken 提交于
-
由 Eric Amodio 提交于
When more than one ext host FileSystemProvider was registered the linkification for the scheme of the provider was causing links to get incorrectly found because the link state machine was setting up the states incorrectly Should hopefully fix MicrosoftDocs/vsonline#28 as well
-
- 06 11月, 2019 3 次提交
-
-
由 Daniel Imms 提交于
Fixes #63052
-
由 Daniel Imms 提交于
-
由 Daniel Imms 提交于
Fixes #62103
-
- 05 11月, 2019 4 次提交
-
-
由 Alex Ross 提交于
First pass at resolving task definition and passing back to custom execution. It only currently resolves simple predefined variables, no input, command, or defaultBuildTask. Part of #81007
-
由 Johannes Rieken 提交于
-
由 Matt Bierner 提交于
This documents the current thinking on the custom editor api. The current api proposal is not actually implemented yet
-
由 Matt Bierner 提交于
For #82514
-