1. 31 12月, 2016 2 次提交
  2. 21 7月, 2016 1 次提交
  3. 16 2月, 2015 1 次提交
  4. 14 1月, 2015 1 次提交
  5. 09 1月, 2015 1 次提交
  6. 07 1月, 2015 1 次提交
    • S
      Make parts of AnalyzerDriver internal by creating shared projects · 644f378d
      srivatsn 提交于
      The IDE uses four public APIs from the compiler layer for doing running analyzers in the IDE:
      
      1. A bunch of static methods on AnalyzerDriver called Execute*Actions which take a type called AnalyzerActions which should be an implementation detail. So first change is to create a shared project called AnalyzerDriver that is referenced by CodeAnalysis and Features layers. I've split out these statics into a type called AnalyzerDriverHelper and made that internal. One challenge in doing this is that these methods create instances of Contexts and currently their constructors are internal. I've added constructors where possible and for some contexts that were taking Scopes, I've changed them to be abstract base classes and eliminated the scopes altogether. As part of pulling these methods, I needed some collections like ArrayBuilder, PooledDictionary etc and created another shared project called SharedCollections and put them there.
      
      2. SemanticModel.GetDeclarationsInSpan - this is used by the IDE to calculate the declarations on which to run analyzers. This has also been pulled into the shared project and the API on semantic model made internal. We need a mechanism for branching into C#\VB implementations on both sides. Hence, the compiler API on semanticmodel still exists and is internal. On the features side, I have a language service, that branches into C#\VB and the implementation simply calls into the shared code.
      
      3,4. AnalyzerDriver.GetEffectiveDiagnsotics and AnalyzerDriver.IsAnalyzerSuppressed() are two APIs about filtering that the IDE uses. There are legitimate scenarios for both of them being public APIs even if we make the IDE simply ask the compiler to run its analyzers. For eg: the IDE will need to run Document analyzers and the compiler can never run them. It needs to filter the results after that. Filtering requires pragma state and suppressmessage etc which are compiler'y things. The plan here is to move these APIs to a type called CompilationWithAnalyzers that John is creating to replace the AnalyzerDriver.GetAnalyzerdiagnostics() method. Once that happens, we can make AnalyzerDriver fully internal. This change doesn't touch those methods.
      
      The shared code needed to access some resources. So I've created a type called AnalyzerDriverResources in both the Codeanalysis and features projects and they redirect to the appropriate resources.
       (changeset 1390439)
      644f378d