1. 28 1月, 2015 1 次提交
  2. 27 1月, 2015 2 次提交
  3. 14 1月, 2015 2 次提交
    • R
      e315208f
    • J
      Move Roslyn to a standard version of xUnit · 022d740b
      jaredpar 提交于
       Change Description:
      
           This change moves Roslyn off of our custom version of xUnit to an official release (xUnit 1.9.2):
      
           - Deletes all of the custom xUnit binaries from Closed\Tools\xUnit
           - Put a subset of the official 1.9.2 binaries with no name mangling into Closed\Tools\xUnit.
           - Rebuilt our custom xUnit GUI (named xunit.gui.custom) against 1.9.2 and put it in Closed\Tools\xUnit
           - Updated the targets file, RunTests.ps1 and Test.exe to refer to the updated binary names.
           - Changed the Roslyn unit tests to work on standard xUnit.
      
           The biggest part of the effort was the last part, getting the tests to run on standard xUnit.  The main issue here was many assumed they would be executed on a single STA thread and as a result cached many thread affinitized values into static fields.  Fixing this involved mostly finding the values and annotating them with [ThreadStatic].
      
           This does mean that MEF composition will happen several times during an xUnit run where before it happened only once.  That is unfortunate but doesn't seem to regress the suites in a significant way on my machine.  Using a multithreaded MEF container isn't an option here because the services end up caching thread affinitized WPF values.
      
           ForegroudThreadAffinitizedObject was the other largest change.  It's use of a static ctor to establish the foreground thread is dangerous and should be correctly addressed in a future change.  For now I added a method for tests to reset the identified foreground thread.
      
           More changes will be coming here for our use of xUnit.  But they should be smaller and more targetted (deleting the extra sources, a better build story for the GUI, etc ...).
      
           Note: Why 1.9.2 instead of 2.0?  We have several uses of custom xUnit extensibility that is not easily portable to 2.0.  Best path forward is to delete that extensibility since it isn't really adding much and move us directly onto 2.0 in a later check in.
      
       (changeset 1395675)
      022d740b
  4. 24 12月, 2014 1 次提交
  5. 11 11月, 2014 1 次提交
  6. 02 11月, 2014 1 次提交
  7. 07 10月, 2014 1 次提交
    • J
      Make much of the Workspaces layer Portable. · e76a29a4
      jasonmalinowski 提交于
      This change splits the Workspaces layer into two parts, mirroring the Portable/Desktop split that the compilers did. The core parts of the Workspaces layer (managing documents and projects, formatting, some refactoring, code fixes) is kept in the portable subset, with a few non-portable pieces remaining, notably MSBuild support.
      
      This change has a major impact on how MEF now works in Roslyn. Traditional MEF (“MEFv1”) is not portable, and so we must move the Workspaces layer over to using the Microsoft.Composition NuGet package (“MEFv2”) which is. The APIs are distinct in that each has its own namespace, but the concepts are more or less identical. It requires some care though: the workspaces layer is simple in that it only references MEFv2, but higher layers have to reference both versions to use metadata attributes. Exports using metadata attributes from the editor (say, ContentTypeAttribute) must use MEFv1 attributes to export, whereas exports for the workspaces layer must use MEFv2 attributes. The rule is subtle and yet simple, and so a diagnostic is provided which catches any offenses to prevent confusion.
      
      This also has some impact in how we create MEF hosts: if you wish to host just the base workspaces layer, we can use MEFv2 to compose everything. The HostServices implementation (MefV1HostServices) that consumes a MEFv1 ExportProvider. If you’re in Visual Studio, you can use this implementation to get the full set of host services provided in Visual Studio.
      
      Otherwise, most of the changes in here are minor: we react to some APIs that have been moved/renamed in the portable subset we are targeting, and also align our various exception helper utilities with the compiler’s precedent. (changeset 1349276)
      e76a29a4
  8. 02 10月, 2014 1 次提交
  9. 10 9月, 2014 1 次提交
    • R
      Rewrite of the native client to improve stability and give better error · c7b038d7
      RoslynTeam 提交于
      messages.
      
      The new native client is written in C++11 to be more maintainable and
      forward-looking. The native client is a static library, which is now
      linked into the csc2 and vbc2 projects instead of having a single csc2.cpp
      file which is shared between the two projects and built for each based on
      a preprocessor definition.
      
      The MSBuildTask is also configured to use csc2/vbc2 and feature no extra
      code for Roslyn, which will prevent us from having to maintain both a
      native and a managed version of the client. (changeset 1325415)
      c7b038d7
  10. 02 7月, 2014 3 次提交
    • S
      In order to validate warning ids that can appear within #Disable directives in... · 56114e0e
      shyamn 提交于
      In order to validate warning ids that can appear within #Disable directives in VB, we need to generate an ErrorFacts helper that will tell us precisely whether or not the specified id is a valid VB warning id (similar to what C# uses to do corresponding validation within #pragmas).
      
      This change adds a simple ErrorFacts generator tool that will be invoked as part of building VB. The implementation is identical to the ErrorFacts generator for C#. (changeset 1287001)
      56114e0e
    • A
      Remove bad projects from Roslyn.sln. (changeset 1286906) · 03e22a51
      angocke 提交于
      03e22a51
    • T
      Renames · 8358dd30
      TomasMatousek 提交于
      rcsc to csc
      rcsi to csi
      rcsc2 to csc2
      rvbc to vbc
      rvbi to vbi
      rvbc2 to vbc2
       (changeset 1285266)
      8358dd30
  11. 20 6月, 2014 2 次提交
  12. 11 6月, 2014 1 次提交
  13. 19 4月, 2014 1 次提交
  14. 18 4月, 2014 1 次提交
  15. 12 4月, 2014 1 次提交
    • N
      Added the first diagnostic analyzer (+tests) which will eventually analyze... · 669ad295
      nslottow 提交于
      Added the first diagnostic analyzer (+tests) which will eventually analyze Roslyn.sln. It produces the following diagnostics:
      RS0001: Use SpecializedCollections.EmptyEnumerable<T>() instead of allocating an array of length 0 or using System.Linq.Enumerable.Empty<T>()
      RS0002: Use SpecializedCollections.SingletonEnumerable<T>() instead of allocating an array of length 1.
      
      In order to get RS0002 completely correct, analyzers need to be able to do data flow analysis, so there are a few skipped tests for now.
      
      In the process of implementing the unit tests, I also pulled the diagnostic analyzer test base into a separate project, DiagnosticsTestUtilities. I updated the analyzer test base to provide output formatted to be immediately usable in test cases, similar to the compiler diagnostics tests. (changeset 1229264)
      669ad295
  16. 08 4月, 2014 1 次提交
  17. 05 4月, 2014 1 次提交
    • N
      Moved FxCop diagnostic analyzer, test, and setup projects into... · 5e666d90
      nslottow 提交于
      Moved FxCop diagnostic analyzer, test, and setup projects into Diagnostics\FxCop folder. Renamed the FxCop analyzer test assembly so as not to be confused with Roslyn.Diagnostics.Analyzers.UnitTests. Added Roslyn diagnostic analyzer projects to Roslyn.sln. (changeset 1223294)
      5e666d90
  18. 28 3月, 2014 2 次提交
  19. 27 3月, 2014 1 次提交
  20. 23 3月, 2014 1 次提交
  21. 20 3月, 2014 1 次提交
  22. 19 3月, 2014 1 次提交