- 12 4月, 2018 1 次提交
-
-
由 Zbyněk Sailer 提交于
-
- 08 4月, 2018 2 次提交
-
-
由 Cyrus Najmabadi 提交于
-
由 Neal Gafter 提交于
Fixes #25991
-
- 07 4月, 2018 9 次提交
-
-
由 Julien Couvreur 提交于
-
由 Heejae Chang 提交于
* moving methods around to clean things up. * more clean up * added comment * more code re-arrange * revert some clean up back since that requires some changes I dont want to do for clean up
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Jonathon Marolf 提交于
-
由 Julien Couvreur 提交于
-
由 Jonathon Marolf 提交于
# Conflicts: # src/EditorFeatures/TestUtilities2/Intellisense/TestState.vb
-
由 Adam Speight 提交于
Add additional information about the found and expected character, when there is an unexpected difference. (#25296)
-
由 Julien Couvreur 提交于
-
- 06 4月, 2018 8 次提交
-
-
由 Alireza Habibi 提交于
Fixes #17261
-
由 Omar Tawfik 提交于
* Produce errors on invalid pdbpath supplied to compiler * More tests
-
由 Sam Harwell 提交于
-
由 Andy Gocke 提交于
The scenario listed in https://github.com/dotnet/roslyn/issues/22700 demonstrates the problem. The direct cause of the crash is that local lowering produces two instances of the lambda and lamda conversions in the resulting bound nodes. This crashes the closure conversion pass since the same lambda cannot appear in two places in the tree. However, even if that were allowed, this would violate the language specification. Placing a lambda inside an indexer which is nested in a compound assignment creates two calls which contain the delegate produced by the lambda expression. If the expression kind is marked as side-affecting it will be spilled into a temporary variable. However, the local lowering doesn't distinguish between whether an expression is side-affecting and whether or not it is referentially transparent. In this case, both matter. Since the delegate produced by the conversion can be compared by reference to any other delegate produced by the same lambda, the code must be referentially transparent -- it must produce the same result when evaluated repeatedly. The fix is small: mark lambda conversions as side-affecting. There are certain cases, like the creation of temporaries for out-of-order calls with named parameters, where the lambda conversion is only required to be non-side-affecting instead of referentially transparent, but it does not currently seem worth the implementation effort to split up the code path. Fixes #22700
-
由 Andy Gocke 提交于
-
由 Andy Gocke 提交于
-
由 Alireza Habibi 提交于
-
由 Sam Harwell 提交于
-
- 05 4月, 2018 12 次提交
-
-
由 Sam Harwell 提交于
See #25931
-
由 Šimon Koníček 提交于
-
由 Dustin Campbell 提交于
-
由 Omar Tawfik 提交于
* Overload Resolution now fails with the correct error * PR Comments * Clean up
-
由 Omar Tawfik 提交于
* Partial methods implementation should match declaration parameter ref kinds * More tests
-
由 JieCarolHu 提交于
-
由 Dustin Campbell 提交于
-
由 Omar Tawfik 提交于
-
由 JieCarolHu 提交于
-
由 JieCarolHu 提交于
-
由 Julien Couvreur 提交于
-
由 Jonathon Marolf 提交于
-
- 04 4月, 2018 8 次提交
-
-
由 Šimon Koníček 提交于
-
由 Omar Tawfik 提交于
* Previous PR comments * Missing tests from test plan * Enable unmanaged constraint on local functions * Clean up * PR Comments * More tests * PR Comments
-
由 Jared Parsons 提交于
This designation will allow Visual Studio to kill instances of VBCSCompiler rather than showing it as blocking update installation. closes #24610
-
由 Heejae Chang 提交于
* fixed bug where all documents are added as high priority on solution load. * add tests
-
由 Dustin Campbell 提交于
Since we're moving this type from Microsoft.CodeAnalysis.Workspaces.Desktop to Microsoft.CodeAnalysis.Workspaces, a type forward is required. There is currently a bug with the Public API analyzer with properties on forwarded types that I have to work around in the PublicAPI.Shipped.txt, but a fix is already out for that https://github.com/dotnet/roslyn-analyzers/pull/1657. Once the analyzers are updated in the roslyn repo, this will get fixed.
-
由 Dustin Campbell 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
This changes the compiler server to be resilient in the face of the Mutex constructor throwing an exception. It's documented as being able to throw various exceptions but we never accounted for it. Had a real world case pop up when using certain Docker containers on Linux. In the case the Mutex ctor throws an exception just fall back to normal csc / vbc execution. The build will complete just fine here, it just won't have the performance boost of the compiler server. closes #24124
-