- 22 4月, 2015 1 次提交
-
-
由 Matt Warren 提交于
-
- 21 4月, 2015 1 次提交
-
-
由 Matt Warren 提交于
-
- 17 4月, 2015 4 次提交
-
-
由 Matt Warren 提交于
-
由 Matt Warren 提交于
-
由 Matt Warren 提交于
-
由 Jared Parsons 提交于
-
- 16 4月, 2015 34 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
Use VB core on our build tools
-
由 jaredpar 提交于
-
由 Manish Vasani 提交于
Update our compiler and diagnostics toolset to the latest signed build. Also disable a unit test that fails with new toolset.
-
由 Manish Vasani 提交于
Also disable a unit test that fails with new toolset.
-
由 Neal Gafter 提交于
-
由 Manish Vasani 提交于
Ensure that speculation analyzer catches replacements which introduces an error type in any of the ancestor expressions. Fixes internal bug 1086771
-
由 Heejae Chang 提交于
don't leak exception when path contains illegal path char
-
由 Heejae Chang 提交于
original watson bug is fixed by using extension manager when we do info ...
-
由 Heejae Chang 提交于
TryCombine should never throw exception.
-
由 Manish Vasani 提交于
Analyzer driver performance improvements to improve command line build throughput with analyzers. These changes bring down the self-build of Roslyn.sln with Roslyn analyzers from 2x of the core build time (build with no analyzers) to ~1.15x on my box. 1.Parallelize compilation event processing: Currently, a single thread processes all compilation events. This is the primary bottleneck for 2x build time with analyzers enabled. However, now that multiple threads process compilation events and execute analyzers, we need to guard against actions running concurrently for the same analyzer instance via a lock. This is accomplished via creating unique gate objects per analyzer instance and locking on them. Deadlock is not possible as these are stored on a private map of the core AnalyzerExecutor, and analyzer callbacks cannot call back into the AnalyzerDriver. 2.Execute syntax node actions for every symbol declared event sequentially: Current approach executes node actions in parallel for different analyzers (though each analyzer's actions are always executed sequentially). Invariably, these action callbacks on different analyzers share the same semantic model, leading to lot of contention on bound node cache accesses, hurting the overall performance. Switching this to completely sequential execution model for each symbol declared event, along with optimization (1) improves the overall performance. There is scope to still fine tune perf here by executing actions with distinct {Analyzer, SemanticModel} tuple in parallel, but I'll leave that for a separate attempt.
-
由 Manish Vasani 提交于
These changes bring down the self-build of Roslyn.sln with Roslyn analyzers from 2x of the core build time (build with no analyzers) to ~1.15x on my box. 1) Parallelize compilation event processing: Currently, a single thread processes all compilation events. This is the primary bottleneck for 2x build time with analyzers enabled. However, now that multiple threads process compilation events and execute analyzers, we need to guard against actions running concurrently for the same analyzer instance via a lock. This is accomplished via creating unique gate objects per analyzer instance and locking on them. Deadlock is not possible as these are stored on a private map of the core AnalyzerExecutor, and analyzer callbacks cannot call back into the AnalyzerDriver. 2) Execute syntax node actions for every symbol declared event sequentially: Current approach executes node actions in parallel for different analyzers (though each analyzer's actions are always executed sequentially). Invariably, these action callbacks on different analyzers share the same semantic model, leading to lot of contention on bound node cache accesses, hurting the overall performance. Switching this to completely sequential execution model for each symbol declared event, along with optimization (1) improves the overall performance. There is scope to still fine tune perf here by executing actions with distinct {Analyzer, SemanticModel} tuple in parallel, but I'll leave that for a separate attempt.
-
由 Jared Parsons 提交于
Let Jenkins specify a custom mono path
-
由 Charles Stoner 提交于
EE: Ignore accessibility in ExpressionLambdaRewriter Fixes #1618
-
-
-
由 Heejae Chang 提交于
-
由 Charles Stoner 提交于
EE: "Static members", etc. should not inherit Access, StorageType, TypeModifierFlags from parent item
-
由 Charles Stoner 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
Currently these build tools takes a dependency on Microsoft.VisualBasic.dll. There is no good implementation of this DLL on Linux which prevented these tools from running there. This in turn prevented us from builing VBC on Linux because they are used in the build process. Change them to instead embed the runtime removing our dependency on Microsoft.VisualBasic.dll.
-
由 Charles Stoner 提交于
-
由 Charles Stoner 提交于
-
由 Charles Stoner 提交于
AsyncRewriter should ignore accessibility in the EE Fixes #1813
-
由 Charles Stoner 提交于
-
由 Jared Parsons 提交于
CoreFx work
-
由 Charles Stoner 提交于
-
由 Tomáš Matoušek 提交于
Remove non-portable dependencies from EEs
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
Changes cibuild.sh to support the --mono-path option. When specified mono from that path will be used in the script instead of the current mono snapshot. This will allow us to extend our CI system to include Mac as well.
-
由 AlekseyTs 提交于
Do not report CS1720 warning when member being accessed is a static member.
-
由 AlekseyTs 提交于
Adjust implementation of LookupPosition.IsInMethodDeclaration to consider an expression body even in presence of a block.
-
由 Jared Parsons 提交于
This adds two scripts that setup a Linux box for building Roslyn. This represents the steps used to configure our Jenkins CI system for Linux. The scripts do the following: - setup.sh: One time machine setup to enable NuGet usage and consumption of mono CI builds - setup-snapshot.sh: Install the latest mono CI package and setup the PCL for that build. These scripts are brand new and should be considered experimental. closes #2007
-
由 Manish Vasani 提交于
Ensure that speculation analyzer catches replacements which introduces an error type in any of the ancestor expressions. Fixes internal bug 1086771
-