- 29 2月, 2020 1 次提交
-
-
由 Manish Vasani 提交于
Move back the ContextQuery related extensions and corresponding SyntaxFact APIs up to the shared WorkspaceExtensions project
-
- 28 2月, 2020 2 次提交
-
-
由 Manish Vasani 提交于
Split `ISyntaxKindsService` into two parts: 1. `ISyntaxKinds`: Pure data query interface, which already exists in CompilerExtensions shared project and can be used by analyzers. 2. `ISyntaxKindsService`: The `ILangaugeService` implementation of `ISyntaxKinds` Above split ensures that we can move the `ISyntaxKindsService` language service implementation down to the WorkspaceExtensions project, which in turn ensures that `GetLanguageService<ISyntaxKindsService>` will always succeed in our entire code base. This is currently not true in CodeStyle fixes layer due to the fact that the language service implementation is defined in Workspaces.csproj
-
由 Manish Vasani 提交于
Split ISyntaxFactsService into two parts: 1. `ISyntaxFacts`: Pure data interface to query about syntactic facts. This is moved to CompilerExtensions shared project and can be used by analyzers. 2. `ISyntaxFactsService`: Derives from ISyntaxFacts and ILanguageService and is present in the WorkspaceExtensions shared project. This enables Code fixes and Workspaces layer to access the same functionality via a language service, i.e. `GetLanguageService<ISyntaxFactsService>`. Note that we cannot use a partial declaration for `ISyntaxFactsService` instead of `ISyntaxFacts`. This causes `ISyntaxFacts` to be defined in both the CodeStyle analyzer and CodeStyle fixer assembly (former imports CompilerExtensions and latter imports WorkspaceExtensions), which leads to type conflicts. We also cannot follow the approach taken for `ISyntaxKindsSevice` as it defines the second partial declaration `ISyntaxKindsSevice` which sub-types `ILanguageService` in Workspaces project, leading to the language service not being defined in CodeStyle fixer assembly, which will cause any code fix requesting `GetLanguageService<ISyntaxKindsService>` to fail. The only feasible approach for us to have the functionality available in shared analyzer layer is to split out the pure data query part of the service to a separate type, as done in this PR. I will send a follow-up PR to also split `ISyntaxKindsService` similarly. Hoepfully, these two are the only language services that are commonly used by our analyzers, and we will not require any more such splits.
-
- 13 2月, 2020 1 次提交
-
-
由 Cyrus Najmabadi 提交于
-