For #81574
See #84669 for details of the problem around strict function types. This change converts `SyncActionDescriptor` to use a static `create` function. This allows us to make the `create` function generic so that it can take the correct types for strictFunctionTypes
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`)
* debt - allow extHostSearch in common
* web - implement text search provider
* fix text search
* Update extensions/vscode-api-tests/src/extension.ts
Co-Authored-By: Rob Lourens <roblourens@gmail.com>
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 fixMicrosoftDocs/vsonline#28 as well
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