1. 14 9月, 2015 1 次提交
  2. 12 9月, 2015 6 次提交
  3. 11 9月, 2015 4 次提交
  4. 10 9月, 2015 2 次提交
  5. 09 9月, 2015 2 次提交
  6. 05 9月, 2015 2 次提交
    • J
      Do not check IgnoreCase in CSharpAddImportCodeFixProvider · 29b716ab
      Jonathon Marolf 提交于
      Remove check for 'IgnoreCase In CSharpAddImportCodeFixProvider we
      explicitly override IgnoreCase to be false.  Therefore, we will never use
      a case in-sesitive comparer.
      29b716ab
    • M
      Fix performance regression in the IDE diagnostic analyzer service. · 4dfefe7b
      Manish Vasani 提交于
      1) Reduce number allocations in the analyzer driver that show up perf traces for Picasso.
      2) Currently we maintain a cache of CompilationWithAnalyzers for projects being actively analyzed. This is causing the VM to rise and also forcing GC to kick in at different phases causing regressions at various scenarios. The fix is to just create a new CompilationCompilationWithAnalyzers instance for each document/project analysis request.
      4dfefe7b
  7. 04 9月, 2015 1 次提交
    • J
      Previously if we added a using inside a namespace we would use a · d4edcef7
      Jonathon Marolf 提交于
      speculative semantic model determine if we should use the fully qualified
      name or not. What this approach failed to account for was if the name
      was going to be simplified further due to the containing namespace. To
      Fix this we run the simplifier over our document and check if there are
      any changes made to the namespace. If this is the case, then we re-sort
      the usings according to the simplified name.
      d4edcef7
  8. 03 9月, 2015 1 次提交
  9. 02 9月, 2015 3 次提交
  10. 26 8月, 2015 4 次提交
  11. 24 8月, 2015 1 次提交
  12. 21 8月, 2015 5 次提交
  13. 20 8月, 2015 2 次提交
    • R
      Dramatically speed up generation of metadata as source for large types · 6417d919
      Ravi Chande 提交于
      Before this change, showing MAS for a type with 4000 empty methods took about 2
      minutes on my machine. With this change, it now takes 2-4 seconds. There were
      2 different issues causing the slow generation:
      
      1. When formatting the generated file, the formatting engine needs to find the
      distance between every token and the new line (or start of file)  before it.
      This calls  TokenStream.GetOriginalColumn, which computes the original column
      by walking backwards through its list of tokens counting the width of tokens
      and trivia until it finds a newline. Though this n ^ 2 operation takes place
      in all invocations of the  formatter, it is normally ameliorated by the fact
      that real code has enough newlines that GetOriginalColumn doesn't actually
      traverse back to the first token in the file. Generated files have no newlines,
      so GetOriginalColumn takes up about half the time of generating a MAS document,
      because GetOriginalColumn is called on every token in the file.
      To mitigate this, we augment MAS' custom formatting rule to not calculate
      anchor indentation. Anchor indentation is what requires the original columns,
      but no operations are produced for MAS documents, which have no newlines
      in them.
      
      2. If instructed to use "auto insertion location", the code generation service
      computes the location to insert each member, one at a time. This computation
      checks that the type's members are sorted, resulting in n ^ 2 iterations over
      the list of members. The fix for this takes Kayle's fix for enum members a
      little further:
      When instructed not to use "auto insertion location", the code generation
      generates declaration syntax for each member without inserting it. It then
      sorts that list of declarations once, and bulks adds them (essentially
      appending each declaration to the end of the growing type declaration).
      
      I've fixed up some of the "Create*Declaration" methods to match the behavior
      of the corresponding "Add*Declaration" methods.
      6417d919
    • J
  14. 19 8月, 2015 6 次提交