1. 19 2月, 2020 1 次提交
  2. 15 2月, 2020 1 次提交
  3. 14 2月, 2020 1 次提交
  4. 31 1月, 2020 1 次提交
  5. 23 1月, 2020 1 次提交
  6. 17 1月, 2020 1 次提交
  7. 16 1月, 2020 1 次提交
  8. 12 11月, 2019 1 次提交
    • A
      MonoGlobalAssemblyCache: faster resolves + resolve facade assemblies (#39369) · fb1b764b
      Aaron Bockover 提交于
      * MonoGlobalAssemblyCache: actually read assembly names from assembly files
      
      new AssemblyName(path) becomes AssemblyName.GetAssemblyName(path)
      
      This fixes the GlobalAssemblyCacheTests when running on Mono.
      
      cf. https://github.com/dotnet/roslyn/pull/39369#issuecomment-545970358
      
      * MonoGlobalAssemblyCache: faster resolves + resolve Facades
      
      1. Don't special case mscorlib.dll - we already will have a reference
         to it, and the changes in (2) allow it to still resolve. Remove
         GetCorlibPaths.
      
      2. Have GetCacAssemblyPaths bail early if it finds an assembly that
         lives alongside mscorlib.dll, or in the Facades directory. This
         These assemblies in Mono are considered "core" and will always
         symlink directly to the GAC. Resolve facade assemblies as well now.
         The Mono distribution of csi has shipped with a response file that
         explicitly referenced Facades/netstandard.dll and
         Facades/System.Runtime.dll and this change obsoletes that. As a
         consequence, local builds of csi.exe now work.
      
      3. Minor perf work around converting a public key token to a string by
         deferring that conversion until only necessary, and use byte.ToString
         instead of AppendFormat. Also use a PooledStringBuilder.
      
      4. Tuple -> ValueTuple
      
      * MetadataShadowwCopyProviderTests: run on Mono
      fb1b764b
  9. 05 11月, 2019 1 次提交
  10. 02 11月, 2019 2 次提交
  11. 01 11月, 2019 1 次提交
  12. 21 9月, 2019 3 次提交
  13. 17 9月, 2019 1 次提交
    • T
      Reuse previously resolved missing assembly metadata objects when identity doesn't match (#38550) · ec85a192
      Tomáš Matoušek 提交于
      * Misc cleanup
      
      * Reuse previously resolved missing assembly metadata objects when identity doesn't match
      
      Background
      When the compiler is resolving compilation references and encounters a reference whose assembly identity does not match any of the explicitly given references it falls back to a Reference Resolver. In regular compilation an error is reported since there is no Reference Resolver. Interactive compiler supplies a resolver that attempts to find the missing reference.
      
      Once the missing reference is found the compiler adds it to the list of implicitly resolved assemblies and if the same missing assembly identity is referenced later (by a subsequent submission) it reuses the assembly symbol from this list, so that we don't end up loading multiple instances of the same missing assembly. [1]
      
      The resolver may find an assembly that matches the name of the missing reference but doesn't match the version exactly. This is expected as a newer version of the assembly may be available than was referenced and the compiler correctly binds to the newer version.
      
      Issues
      The first submission added a reference to a netstandard20 library on .NET Core and the subsequent submission referenced a type from that library. The reference resolution in the compilation corresponding to the second submission ended up adding a new, distinct reference to the library, instead of reusing the one that was already resolved for the first submission compilation.
      
      This was caused by mismatch in versions of some of the facades transitively referenced by the library thru netstandard.dll reference and resolved thru the missing reference resolution mechanism. The facades ware referenced with different versions than the actual versions available in the set of references the Reference Resolver resolved missing references from. The compiler ended up using two distinct instances of the same facade assembly metadata. An assembly symbol is only reused if all its transitively referenced assemblies match. In this case the library assembly symbol wasn't reused because some of the facade assembly symbols did not match.
      
      The problem was that the mechanism [1] didn't reuse missing assembly metadata with a different version than what was requested. The fix is to check whether we have seen an assembly with the resolved identity in addition to the requested identity.
      
      Another issue found during testing is handing resolution failures. We did not remember that a resolution of a given assembly identity failed and attempted to resolve the assembly again in the next submission. This may lead to inconsistencies and the same "can't convert T to T" errors since first submission might have a missing assembly symbol and next might create a real assembly symbol for the same assembly identity. The fix is to capture both successful and failed resolution results.
      
      * Do not add resolved identity entry to implicit reference resolutions
      ec85a192
  14. 10 9月, 2019 1 次提交
  15. 07 9月, 2019 1 次提交
  16. 05 9月, 2019 1 次提交
  17. 04 9月, 2019 1 次提交
  18. 31 8月, 2019 1 次提交
  19. 29 8月, 2019 1 次提交
  20. 28 8月, 2019 1 次提交
    • M
      Remove System.Runtime.Loader hack · 3e9505e9
      Marius Ungureanu 提交于
      Microsoft.CodeAnalysis.Scripting now targets NS2.0, so the custom package is no longer needed.
      Should fix a composition error in VSMac, due to the fact that we don't ship the dll from this nuget
      3e9505e9
  21. 29 6月, 2019 1 次提交
  22. 24 6月, 2019 1 次提交
  23. 22 6月, 2019 1 次提交
  24. 21 6月, 2019 1 次提交
  25. 24 5月, 2019 1 次提交
  26. 16 5月, 2019 2 次提交
  27. 10 5月, 2019 2 次提交
  28. 02 5月, 2019 1 次提交
    • T
      Project cleanup (#35403) · e051790e
      Tomáš Matoušek 提交于
      * Remove RoslynProjectType
      
      * Remove ToolsVersion, namespace from Project tags
      
      * Remove updating of MSBuildAllProjects
      
      * Update BuildBoss
      
      * Delete DeployTooolsetCompiler
      e051790e
  29. 19 4月, 2019 2 次提交
  30. 18 4月, 2019 1 次提交
  31. 29 3月, 2019 1 次提交
  32. 27 3月, 2019 1 次提交
    • F
      Track nullability in script code (#33096) · 7f809efa
      Filip W 提交于
      * Analyze nullability in script initializer
      
      * C# 8 for scripts for now
      
      * nullable context script test
      
      * extra null check
      
      * added possibility to set c# Language Version on ScriptOptions
      
      * adjust tests
      
      * added ScriptOptionsTests for C# lang version
      
      * adapted tests after rebase
      
      * code review changes
      
      * fixed test names & resx CDATA
      
      * changed the ScriptOptions.WithLanguageVersion error message text and moved it to ScriptingResources.resx
      
      * Update CSharpScriptingResources.Designer.cs
      7f809efa
  33. 25 3月, 2019 1 次提交
  34. 23 3月, 2019 1 次提交