-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merging Dev15.7.x into features/stackalloc-init #25430
Merged
VSadov
merged 53 commits into
dotnet:features/stackalloc-init
from
VSadov:stackallocMerge
Mar 13, 2018
Merged
Merging Dev15.7.x into features/stackalloc-init #25430
VSadov
merged 53 commits into
dotnet:features/stackalloc-init
from
VSadov:stackallocMerge
Mar 13, 2018
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…e picked up by all roslyn languages).
…agnosticAnalyzer.GetLeftmostCondition Fixes dotnet#25237
Remove a non-fatal Watson report that was triggering frequently and causing UI delays. We expected that all references to a project would be removed before the project itself was unloaded, and this report was added to help us diagnose the rare occasion when that did not occur. It turns out that it happens quite frequently: when a solution closes, when a project changes externally and needs to be reloaded, and when a project is deleted from the solution. We're getting a lot more of these events than expected, and worse, collecting the Watson data sometimes causes long pauses in the UI. We do not have a concrete plan for dealing with the underlying issue, but the data we've already collected from these reports demonstrates the scope of the problem and collecting more won't help at this point. Since the collection itself is causing problems, it's time to just remove it.
Add a comment to make it clear that we don't expect other projects to still be referencing the project being `Disconnect`ed, and why we're protecting against it.
….7-preview1 Merge dev15.6.x to dev15.7-preview1
Handle return statements with no expression in CSharpAsAndNullCheckDi…
* Move common parts of Microsoft.CSharp.Core.targets and Microsoft.VisualBasic.Core.targets to Microsoft.Managed.Core.targets
…ions Move checking of structure-options to a common location (so it will be picked up by all roslyn languages).
Remove NFW causing delays
* Refactor Windows PDB writer
…ists Visual Basic argument lists (and other parenthesized lists, like parameter lists and type parameter lists), have specialized smart indent behavior. Essentially, arguments after the first argument in a list are indented to the same position as the first argument. Consider the following code. ``` VB Sub M() Console.WriteLine("{0} + {1} = {2}", 19, 23, 19 + 23) End Sub ``` If the user presses ENTER before the second argument (19), the indentation looks like so. ``` VB Sub M() Console.WriteLine("{0} + {1} = {2}", 19, 23, 19 + 23) End Sub ``` However, this can cause indentation issues if the user wants to ident all subsequent arguments differently. Consider the following scenario. ``` VB Sub M() Console.WriteLine("{0} + {1} = {2}", 19, 23, 19 + 23) End Sub ``` Now, if the user presses ENTER before the third argument (23), the indentation of the first argument will be used, even though the user had indented the second argument differently: ``` VB Sub M() Console.WriteLine("{0} + {1} = {2}", 19, 23, 19 + 23) End Sub ``` This problem occurs because a single indent block operation is created for the whole argument list using the indentation of the first argument. This change fixes the issue by creating multiple indent block operations using the indentation of the first argument, and the indentation of any argument that appears on a different line.
The ability to verify IL is presently a runtime specific operation. Moved the logic to enforce the test conforms to the specified behavior into the runitme layers.
Needed the split between the netstandand and desktop version of the reference to be more explicit.
This updates the CoreClr test infrastructure to include verifying the metadata signaturse of the emitted code. There is not 100% parity due to the inability to read custom attribute data on parameters, fields, etc ... But that covers only a small number of test cases. Destructor tests now passing.
Key problem with the tests is they were being run in parallel. This is due to using CoreClr which doesn't respect our .config based options. Also fixed bad uses of Thread.Abort in the try finally tests which were causing resource cleanup issues 147 failures remaining to handle
This conditions the use of SigningTestHeplers to only be in the net461. In the long term this type needs to be changed to be portable friendly. Filed the following bug to track dotnet#25228
Cherrypick from dotnet#25071
Enable C# emit tests on CoreClr
….7-preview1 Merge dev15.6.x to dev15.7-preview1
….7.x Merge dev15.6.x to dev15.7.x
…on a line is not the first token and is split across multiple lines
* Extract common code to a helper method
Adjust indent block operations used for VB smart indent in argument lists
This change adds an OutputRefFilePath path to the workspace API for the compiler's /refout feature.
We can rely on IFormattable instead
…v15.7-preview1-to-dev15.7.x
The Roslyn code base defaults to enabling the `<DisableImplicitFrameworkReferences>` property and instead specifies manual references. This is mostly an artifact of our code base evolution from the project.json days where implicit references weren't an option. This means that even though TestUtilities specified netcoreapp2.0 as a TF it was still mostly targeting netstandard1.3. This is because implicit references weren't expanded and we were manually adding only a subset of the available packages. Enabled implicit references here, conditioned the explicit ones to netstandard1.3 and now we can remove a number of `#if` uses. closes dotnet#25228
…o-dev15.7.x Merge dev15.7-preview1 to dev15.7.x
This is referenced in the TestUtilities.csproj but for some reason not explicitly copied to the output folder here. Manually adding for now. dotnet/sdk#2035
Add Project.OutputRefFilePath and ProjectInfo.OutputRefFilePath
Fix netcoreapp2.0 use in TestUtilities
@alrz - FYI. We should start tracking Dev15.7.x now. That will be the target branch for the feature merge. |
@dotnet-bot test windows_release_vs-integration_prtest please |
@dotnet-bot test windows_release_unit32_prtest please |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Dev15.7.x will be the eventual target branch for the feature merge.
(features/compiler is being retired)
Trivial merge with no merge conflicts - since we have just merged from features/compiler which is still fairly up-to-date.