- 03 1月, 2017 1 次提交
-
-
由 Charles Stoner 提交于
-
- 30 12月, 2016 5 次提交
-
-
由 Jared Parsons 提交于
Fix our use of suppressParent in project.json
-
由 Jared Parsons 提交于
On machines with Dev15 installed there are additional DLLs in the set of assemblies that can be referenced by default. The SDK adds them by default. This introduced a new confilct that needed to be resolved.
-
由 Jared Parsons 提交于
TLDR: This change removes our use of suppressParent which should not be used The core problem in our build setup which lead to the use of suppressParent is having the same reference DLL introduced by different NuGet packages. These packages differed in name and version from each other. The most notable example is the reference DLL for Microsoft.VisualStudio.Language.NavigateTo.Interfaces.dll which is contained in 3 different NuGet packages: - RoslynDependencies.Microsoft.VisualStudio.Language.NavigateTo.Interfaces 14.0 - Roslyn.Microsoft.VisualStudio.Language.NavigateTo.Interfaces 15.0 preview 5 - Microsoft.VisualStudio.Language.NavigateTo.Interfaces 15.0 RC The differing names is a problem because when resolving conflicts NuGet doesn't consider the referenced DLL versions at all (by design). Instead it is only concerned with handling conflicts between packages of the same name. These packages have different name and hence NuGet never attempts to do any conflict resolution between them. It will consider each package to be a separate entity and pass on their assets to MSBuild. This means that MSBuild will eventually be handed the same DLL with 3 different versions and consequently begins issuing MSB3277 errors. The suppressParent entries in the project.json file suppressed this error because it essentially removes the listed package from the transitive graph. Hence it never appeared in referenced projects, only a single DLL was passed to MSBuild and compilations progressed. This is the wrong approach to fixing that problem because it's subverting both the depenedncy conflict resolution aspects of NuGet / MSBuild and causing us to create incomplete deployments in our unit test directories. This is fighting the tooling instead of leveraging it. The more robust approach to solving this problem is to have a reference DLL always distributed through the same NuGet package. This allows NuGet to handle the version conflicts using standard conflict rules and resulting in only a single DLL being passed to MSBuild. In the past this has been a blocker because we often need DLLs at versions that aren't available on NuGet. Going forward we will be working with the VSSDK to remedy that problem. Short term though we are simply going to upload ad-hoc packages with the correct name to the roslyn-tools feed using the pre-release moniker -alpha. This ensures we don't have any conflicts with official packages on NuGet.org. There are a few cases this change doesn't completely address that I want to call out: - Types moved between the MS.VS.Shell.Immutable and MS.VS.Shell.Framework DLLs between Dev14 and Dev15. To prevent a lot of duplicate type errors the MS.VS.Shell.Immutable DLLs need to be removed from the compile graph, but not the runtime graph, in our Next projects. - GraphModel is an adhoc package created by us that doesn't have an existing NuGet package to pattern off of and it's not obvious how such a package would be laid out if it existed. The Dev15 packages also include this as a reference by default which causes a confilct with our packages. As such I've used "include: none" for now to work around the problem until a final NuGet package is decided on.
-
由 Vladimir Sadov 提交于
Added a test to validate that __refvalue is not allowed to be returned by reference
-
由 CyrusNajmabadi 提交于
Improve performance of code-style analysis.
-
- 29 12月, 2016 19 次提交
-
-
由 VSadov 提交于
-
由 Tanner Gooding 提交于
Cleaning up the Roslyn build configurations
-
由 Vladimir Sadov 提交于
Better codegen quality when emitting degenerate switches.
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
Related to dotnet/coreclr#7914 Where the offending pattern was observed in the IL generated for the Kestrel web server and was recommended as an easy improvement. Becasue of cascaded dispatching into "try" regions , it is not uncommon to see async state machine to contain degenerate switches like IL_0008: switch ( IL_003b, IL_003b, IL_003b, IL_003b, IL_003b, IL_003b, IL_003b, IL_0729) Note numerous cases all leading to the same target. We can trivially emit such switches as just a range-check (that switch would need to do anyways), without any actual "switching". Since all cases lead to the same label anyways, there is no need to switch once we know the value is in range of the switch. Fixes:#14878
-
由 Tanner Gooding 提交于
Disable the vs-integration tests from running with PRs by default.
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 Tanner Gooding 提交于
-
由 AlekseyTs 提交于
Fix a crash caused by an improper reuse of lambdas from return inference cache.
-
- 28 12月, 2016 15 次提交
-
-
由 Manish Vasani 提交于
Ensure that CPS property setters also invoke the code within ExecuteF…
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
Similar change as to TestUtilities. Insteading of having two independent projects with shared sources there are now a portable and desktop only version. The desktop version references the portable one.
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
Clean up the remaining solutions to have the utilities included.
-
由 Jared Parsons 提交于
Fix the factored out runtime code to properly execute the compiler compiled test code in AppDomains.
-
由 Jared Parsons 提交于
Code move before refactoring it.
-
由 Jared Parsons 提交于
The Compilers.sln solution is compiling again and tests which don't require AppDomain support are running again. There is a bit of work that is needed for AppDomains that I want to separate out. In particular the separation to portable means we have to redo some of the serialization code.
-
由 Jared Parsons 提交于
The TestUtilities project should be our portable unit test helper. This is part one of rearranging our sources to reflect that reality. I'm separating it out because it involves a significant code move that will make the actual rework part harder to review.
-
由 Jared Parsons 提交于
This is the project which will hold the CoreClr capabilities for our test infrastructure. In particular it will hold the code for using AssemblyLoadContext to manage our isolated test boundaries.
-