- 12 3月, 2020 1 次提交
-
-
由 Fred Silberberg 提交于
Co-Authored-By: NJared Parsons <jaredpparsons@gmail.com>
-
- 11 3月, 2020 1 次提交
-
-
由 Fredric Silberberg 提交于
-
- 22 1月, 2020 1 次提交
-
-
由 Maher Jendoubi 提交于
-
- 23 11月, 2019 1 次提交
-
-
由 Tomáš Matoušek 提交于
-
- 07 8月, 2019 1 次提交
-
-
由 Jared Parsons 提交于
There are a few parts to this change: 1. Ensure that MSB3270 and MSB3277 warnings are promoted to errors in CI and hence block merging. 1. Move our DiaSymReader.Native logic into a separate targets file. This resource cannot be consumed with a simple package reference but rather requires a package reference and custom logic to pull out the contained binaries. This logic used to be spread through our build. Now it's in a single place. 1. Remove the x86 bootstrapping logic. This was testing a pretty obscure scenario and the cost of maintaining that logic is siginificant at this point. Can bring back if we ever find a bug in this area. The root cause of the MSB3270 warnings is a subtle change in the SDK. It now passes the runtime graph to NuGet for native assets. In the case of DiaSymReader.Native there are runtime specific assets hence the SDK / NuGet had to pick one for framework projects. This eventually lead to `PlatformTarget` being set to x86 where it shoud have been AnyCPU. Part of the change includes adding `ExcludeAssets=all` to the package reference which means they no longer figure into this logic and hence the binaries are marked as AnyCPU. This regression in behavior is being tracked by https://github.com/dotnet/sdk/issues/3495
-
- 02 8月, 2019 1 次提交
-
-
由 Jared Parsons 提交于
There are a few parts to this change: 1. Ensure that MSB3270 and MSB3277 warnings are promoted to errors in CI and hence block merging. 1. Move our DiaSymReader.Native logic into a separate targets file. This resource cannot be consumed with a simple package reference but rather requires a package reference and custom logic to pull out the contained binaries. This logic used to be spread through our build. Now it's in a single place. 1. Remove the x86 bootstrapping logic. This was testing a pretty obscure scenario and the cost of maintaining that logic is siginificant at this point. Can bring back if we ever find a bug in this area. The root cause of the MSB3270 warnings is a subtle change in the SDK. It now passes the runtime graph to NuGet for native assets. In the case of DiaSymReader.Native there are runtime specific assets hence the SDK / NuGet had to pick one for framework projects. This eventually lead to `PlatformTarget` being set to x86 where it shoud have been AnyCPU. Part of the change includes adding `ExcludeAssets=all` to the package reference which means they no longer figure into this logic and hence the binaries are marked as AnyCPU. This regression in behavior is being tracked by https://github.com/dotnet/sdk/issues/3495
-
- 24 4月, 2019 1 次提交
-
-
由 Jared Parsons 提交于
This changes our bootstrap compiler to run as a 32 bit process in the 32 bit CI runs. The intent of this runs is to validate we can function on 32 bit systems and that should extend to the compiler as well. This can help us identify the rare cases where we emit code that doesn't perform well on the 32 bit JIT, or just outright crashes.
-
- 30 3月, 2019 1 次提交
-
-
由 Jared Parsons 提交于
Two space indent is an abomination but it's the standard that Arcade chose. Moving our Powershell to be consistent with the standard.
-
- 29 3月, 2019 2 次提交
-
-
由 Tomáš Matoušek 提交于
-
由 Tomáš Matoušek 提交于
-
- 02 3月, 2019 1 次提交
-
-
由 Sam Harwell 提交于
-
- 26 2月, 2019 1 次提交
-
-
由 Jared Parsons 提交于
-
- 20 2月, 2019 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Read IBC and VS bootstrapper info from PublishData.json * Fix IBC directory path
-
- 07 2月, 2019 1 次提交
-
-
由 Tomáš Matoušek 提交于
-
- 15 1月, 2019 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Arcade SDK 1.0.0-beta.19054.11 * Consolidate OptProf scripts * Use raw IBC data from VSTS drop
-
- 18 12月, 2018 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Fix issues with using dogfood compilers * Replace Restore-Project with Run-MSBuild. Run-MSBuild sets various properties based on global variables that were not set in Restore-Project.
-
- 12 12月, 2018 1 次提交
-
-
由 Jared Parsons 提交于
The point of using the bootstrap compiler is validating that we can build the C# code base with the latest C# compiler. Unfortunately the debug version of the compiler is significantly slower than the Release version and it slows down our Debug unit test runs accordingly. This change causes us to prefer a release version of the bootstrap compiler. The debug bootstrap compiler is still used in the determinism leg hence we wont't lose coverage here. This should bring our Release and Debug desktop tests back to the same run time.
-
- 11 12月, 2018 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Remove RuntimeIdentifier specification * Arcade directory layout
-
- 07 12月, 2018 1 次提交
-
-
由 Tomáš Matoušek 提交于
-
- 28 11月, 2018 2 次提交
-
-
由 Tomas Matousek 提交于
-
由 Tomas Matousek 提交于
-
- 30 10月, 2018 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Use Arcade dotnet install scripts * Update roslyn-tools build tasks to 1.0.0-beta3.18523.2 * DotNet version check, remove LocateDotNet.
-
- 19 10月, 2018 1 次提交
-
-
由 Jared Parsons 提交于
The `&` operator in Powershell does not easily allow arguments to be conditionally emitted into a command. This is because instead of inserting string contents when using variable replacement it will insert a quoted string instead. Using `Exec-Process` instead as it does proper substitution
-
- 01 8月, 2018 1 次提交
-
-
https://dot.net由 Jason Malinowski 提交于
https://github.com/dotnet/announcements/issues/77 for the change and where I am stealing this change from.
-
- 27 7月, 2018 1 次提交
-
-
https://dot.net由 Jason Malinowski 提交于
https://github.com/dotnet/announcements/issues/77 for the change and where I am stealing this change from.
-
- 20 7月, 2018 1 次提交
-
-
由 Jason Malinowski 提交于
On our 15.8 machines, there aren't release versions...because we haven't released it yet.
-
- 23 6月, 2018 1 次提交
-
-
由 Jared Parsons 提交于
-
- 08 6月, 2018 1 次提交
-
-
由 Tomáš Matoušek 提交于
* Orchestrated build dependency uptake * Remove duplicate NuGetPackageRoot definition
-
- 12 4月, 2018 1 次提交
-
-
由 Jared Parsons 提交于
Moved the last of our NuGet package creation over to dotnet. Deleted all remaining infrastructure for using NuGet.exe.
-
- 28 3月, 2018 1 次提交
-
-
由 Jared Parsons 提交于
In the case the CLI was previously downloaded but not yet on `%PATH%` we need to manually add it there. Not doing it leads to cases where MSBuild can't find the proper SDK and as a result failing the build. closes #25649
-
- 21 3月, 2018 1 次提交
-
-
由 Jared Parsons 提交于
-
- 20 3月, 2018 2 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
DevDivInsertionFiles.vbproj is the last project which isn't included in Roslyn.sln. Included it there and remove the solution that used to drive it's build.
-
- 14 2月, 2018 1 次提交
-
-
由 Sam Harwell 提交于
-
- 13 2月, 2018 1 次提交
-
-
由 Sam Harwell 提交于
-
- 03 2月, 2018 1 次提交
-
-
由 dotnet bot 提交于
* Remove duplicate lock DocumentState.s_syntaxTreeToIdMapLock This lock is only being used to protect access to an instance which contains internal synchronization. * Better handle surrounding directives when inlining a local variable. * Add tests. * Share code between VB and C#. * Reduce allocations in UnboundLambda Fixes #23463 * Restore ReturnInferenceCacheKey as the key for _returnInferenceCache * Update code to more closely follow patterns of the original code * Cleanup from code review * basic fix for intellisense in Immediate window * better comments and cleanup * Add basic integration tests * cleanup inproc Immediate window integration test helper * fix incorrect comment * address PR feedback * create Immediate window on ImmediateWindow_InProc.GetText() * Verify MSBuild version in Developer CMD prompt Roslyn is designed to have the simplest possible contribution story: clone then build. Every pre-req needed is either located on the machine or bootstrapped via NuGet. All the way down to using an xcopy MSBuild if needed. The one case which causes a problem is the VS command prompt. In this case MSBuild is pre-installed on the machine and may or may not be suitable for building Roslyn. Previously when building from a VS command prompt we just used whatever MSBuild was provided. The assumption being a developer command prompt was an explicit statement of whath MSBuild you wanted to use. Based on all of our customer reports though this does not seem to be the assumption that consumers of our repo have. The build gave them no explicit errors about the provided toolset and hence when the build failed they assigned flakiness to our repo. Going forward we are applying the same version validation to MSBuild when provided via a developer command prompt. If it doesn't match we will refuse to build asking the user to upgrade VS or build from a normal command prompt. * Remove unneeded debugging line * Comment about pre-release * Added minimum version * Add Omit If Default style option * Add space to be like test without the omit * Add/Remove without needing a property * Reformat * PR feedback * Fix VB diagnostic based on feedback * Handle case of NotApplicable modifier and field declaration list * Fix tests * PR feedback * PR feedback * PreviewCodeAction was overriding ComputeOperations but returning a post-processed operation from original action. This results in another PostProcess being called on the codeaction. If postprocess was overriden in originalaction that'll be ignored the second time (#23920) * Support negative null-check when we are suggesting to inline type checks Fixes #21097 Fixes #24286 * fix a case where persistent storage registration fails and some clean… (#24458) * fix a case where persistent storage registration fails and some clean up code around it. * added readonly * address PR feedback * removed comments no longer relevant * renamed lock name * moved waiter from diagnostics.dll to features.dll where all interfaces are defined. (#24512) * put listener change back in (https://github.com/dotnet/roslyn/pull/24120) * leave old types in legacy folder until partner teams move to new interface * added legacy waiter to support partner teams * Remove methods indirecting access to _metadataFileNameToConvertedProjectReference This field is documented as being written and read from any thread, but in practice all uses are guarded by an AssertIsForeground(). Thus we can get rid of the helper methods that are trying to "help" by locking before accessing the fields, making it really hard to track all the real uses of it. * Make method static that doesn't need state * add a comment to address PR feedback * Fix up tests of P2P to metadata reference conversion It turns out we had some tests, but the tests were disabled. This was because the tests weren't working properly anyways: they were calling into UpdateProjectBinPath which only updated some (but not all) of the project state. That was an internal helper method that shouldn't be used by tests. Updating the tests to use SetBinOutputPathAndRelatedData works better. * Delete debug-only reference validation This was some legacy code that tried to verify that the references we have from the project system match up to what DTE and other sources say. This was debug-only, and the actual asserts were commented out. This is deadweight at this point, so delete it. * added and cleaned up logs around build and live diagnostics. (#24551) also added RoslynActivityLogger that can be enabled through project-system-tool * Avoid closure allocations on the BindSyntaxTreeToId fast path * CS1628 error text mentions in parameters; fixes #24584 * Small cleanup of completion logic. * Move to xunit.console for CoreClr tests Previously we were using xunit.console for desktop tests and dotnet-xunit for our CoreClr tests. This change unifies us on top of xunit.console (now that it has a netcoreapp2.0 version available). * Move unix builds to xunit.runner.console as well * Get actual directory name, not file * Fix dir name issue * fixed build break
-
- 31 1月, 2018 4 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
Roslyn is designed to have the simplest possible contribution story: clone then build. Every pre-req needed is either located on the machine or bootstrapped via NuGet. All the way down to using an xcopy MSBuild if needed. The one case which causes a problem is the VS command prompt. In this case MSBuild is pre-installed on the machine and may or may not be suitable for building Roslyn. Previously when building from a VS command prompt we just used whatever MSBuild was provided. The assumption being a developer command prompt was an explicit statement of whath MSBuild you wanted to use. Based on all of our customer reports though this does not seem to be the assumption that consumers of our repo have. The build gave them no explicit errors about the provided toolset and hence when the build failed they assigned flakiness to our repo. Going forward we are applying the same version validation to MSBuild when provided via a developer command prompt. If it doesn't match we will refuse to build asking the user to upgrade VS or build from a normal command prompt.
-