Merge main to release/dev17.13

CONTRIBUTING.md

@@ -0,0 +1,106 @@
+# Contributing to F#
+
+One of the easiest ways to contribute is to participate in discussions on GitHub issues. You can also contribute by submitting pull requests with code changes.
+
+## General feedback and discussions?
+
+Start a [discussion](/~https://github.com/dotnet/fsharp/discussions) on the [repository issue tracker](/~https://github.com/dotnet/fsharp/issues).
+
+## Bugs and feature requests?
+
+❗ **IMPORTANT: If you want to report a security-related issue, please see the `Reporting security issues and bugs` section below.**
+
+Before reporting a new issue, try to find an existing issue if one already exists. If it already exists, upvote (👍) it. Also, consider adding a comment with your unique scenarios and requirements related to that issue.  Upvotes and clear details on the issue's impact help us prioritize the most important issues to be worked on sooner rather than later. If you can't find one, that's okay, we'd rather get a duplicate report than none.
+
+If you can't find an existing issue, log a new issue in this GitHub repository.
+
+## Creating Issues
+
+- **DO** use a descriptive title that identifies the issue to be addressed or the requested feature. For example, when describing an issue where the compiler is not behaving as expected, write your bug title in terms of what the compiler should do rather than what it is doing – “F# compiler should report FS1234 when Xyz is used in Abcd.”
+- **DO** specify a detailed description of the issue or requested feature.
+- **DO** provide the following for bug reports
+  - Describe the expected behavior and the actual behavior. If it is not self-evident such as in the case of a crash, provide an explanation for why the expected behavior is expected.
+  - Provide an example with source code / projects that reproduce the issue.
+  - Specify any relevant exception messages and stack traces.
+- **DO** subscribe to notifications for the created issue in case there are any follow up questions.
+
+## Reporting security issues and bugs
+
+Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC)  secure@microsoft.com. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the [Security TechCenter](https://technet.microsoft.com/security/ff852094.aspx).
+
+## Writing Code
+
+### Finding an issue to work on
+
+  Over the years we've seen many PRs targeting areas, which we didn't plan to expand further at the time.  In many of these these cases we had to say `no` to those PRs and close them. That, obviously, is not a great outcome for us. And it's especially bad for the contributor, as they've spent a lot of effort preparing the change.
+  To resolve this problem, we've decided to separate a bucket of issues, which would be great candidates for community members to contribute to. We mark these issues with the `help wanted` label. [help wanted](/~https://github.com/dotnet/fsharp/labels/help%20wanted)
+
+  Within that set, we have additionally marked issues that are good candidates for first-time contributors. Here: [Good first issue](/~https://github.com/dotnet/fsharp/labels/good%20first%20issue)
+
+  If you would like to make a contribution to an area not documented here, first open an issue with a description of the change you would like to make and the problem it solves so it can be discussed before a pull request is submitted.
+
+### The primary customers of the F# repository are users of the dotnet SDK, Visual Studio, Rider and Ionide. At all times their experience is paramount in our mind.
+
+  We are very accepting of community pull requests, there are however, a set of firm considerations that we hold to when reviewing PRs and determining what to merge.  These have been developed over the years to maintain the quality of the product and the experience that F# developers have when installing and upgrading the dotnet SDK and Visual Studio.
+
+- Does the change fix something that needs fixing, is there an issue, does the issue indicate a real problem?
+- Does the change improve the readability of something that needs improvement?
+- Does the change add a feature that is approved for adding?
+- Does the code match or improve of the existing codebase?
+- Is the performance improvement measured and can regressions be identified?
+- Will our existing customers be able to without effort upgrading the **Major** release of an SDK or VS?
+- Will our existing customers be able to without effort upgrading the **Minor** release of an SDK or VS?
+- This change is not binary breaking (i.e. does not break VS, Rider or Ionide)?
+- Does it have adequate testing?
+- Do all existing tests run unmodified?
+
+In general answers to the above should be **Yes**.  A **No** to any of them is not disqualifying of the PR, however a no answer will need an explanation and a discussion.
+
+There are additional considerations
+- Is the risk of accepting this change High or even Medium, these really refer to how much of the existing user or codebase is impacted. How likely do we feel we are to revert the changes later.
+  For an acceptable PR with a high risk, we will definitely need to discuss mitigations for the risk.  A decision to upgrade the SDK or VS needs to be always low risk for our customers, they have businesses to run, they don't want to have to deal with our - risky behavior.  We may defer or delay risky PRs into a later release or abandon it.
+- Is the change as small as possible
+- Should it be chopped up into smaller, yet independently valuable and releasable to production, chunks
+- Is the cost of reviewing the change worth the improvement made by the change
+Again, some PR’s are too big or provide too little value to merge.
+
+
+### Resources to help you get started
+
+Here are some resources to help you get started on how to contribute code or new content.
+
+- [Developers Guide](/~https://github.com/dotnet/fsharp/blob/main/DEVGUIDE.md) to get started on building the source code on your own.
+- [Test Guide](/~https://github.com/dotnet/fsharp/blob/main/TESTGUIDE.md) how to build run and work with test cases.
+- [F# compiler guide](/~https://github.com/dotnet/fsharp/blob/main/docs/index.md)
+- [F# language specification](https://fsharp.org/specs/language-spec/)
+- [F# language design](/~https://github.com/fsharp/fslang-design/)
+- [F# language suggestions](/~https://github.com/fsharp/fslang-suggestions/)
+- [help wanted](/~https://github.com/dotnet/fsharp/labels/help%20wanted) where to start
+
+### Submitting a pull request
+
+You will need to sign a [Contributor License Agreement](https://cla.dotnetfoundation.org/) when submitting your pull request. To complete the Contributor License Agreement (CLA), you will need to follow the instructions provided by the CLA bot when you send the pull request. This needs to only be done once for any .NET Foundation OSS project.
+
+If you don't know what a pull request is read this article: <https://help.github.com/articles/using-pull-requests>. Make sure the repository can build and all tests pass. Familiarize yourself with the project workflow and our coding conventions. 
+
+- **DO** ensure submissions pass all Azure DevOps legs and are merge conflict free.
+- **DO** submit language feature requests as issues in the [F# language](/~https://github.com/fsharp/fslang-suggestions) repos.  Please note: approved in principle does not guarantee acceptance.
+- **DO NOT** submit language features as PRs to this repo first, or they will likely be declined.
+- **DO** submit issues for other features. This facilitates discussion of a feature separately from its implementation, and increases the acceptance rates for pull requests.
+- **DO NOT** submit large code formatting changes without discussing with the team first.
+
+### Reviewing pull requests
+
+Our repository gets a high volume of pull requests and reviewing each of them is a significant time commitment. Our team priorities often force us to focus on reviewing a subset of the active pull requests at a given time.
+
+### Feedback
+
+Contributors will review your pull request and provide feedback.
+
+## Merging pull requests
+
+When your pull request has had the feedback addressed, and it has been signed off by two or more core team reviewers with commit access, and all checks are green, we will commit it.
+
+## Code of conduct
+
+See [CODE-OF-CONDUCT.md](./CODE-OF-CONDUCT.md)

DEVGUIDE.md

@@ -228,7 +228,8 @@ dotnet test tests/FSharp.Compiler.Service.Tests/FSharp.Compiler.Service.Tests.fs
 
 ### Updating ILVerify baselines
 
-These control IL for the core modules of the compiler. The baselines are located in the `eng` folder and look like:
+These are IL baseline tests for the core assemblies of the compiler (FSharp.Core and FSharp.Compiler.Service). The baselines are located in the `tests/ILVerify` folder and look like:
+
 ```
 ilverify_FSharp.Compiler.Service_Debug_net9.0.bsl
 ilverify_FSharp.Compiler.Service_Debug_netstandard2.0.bsl
@@ -240,7 +241,10 @@ ilverify_FSharp.Core_Release_netstandard2.0.bsl
 ilverify_FSharp.Core_Release_netstandard2.1.bsl
 ```
 
-If you want to update them, run the [ilverify.ps1]([url](/~https://github.com/dotnet/fsharp/blob/main/eng/ilverify.ps1)) script in PowerShell. The script will create `.actual` files. If the differences make sense, replace the original baselines with the actual files. 
+If you want to update them, either
+
+1. Run the [ilverify.ps1]([url](/~https://github.com/dotnet/fsharp/blob/main/tests/ILVerify/ilverify.ps1)) script in PowerShell. The script will create `.actual` files. If the differences make sense, replace the original baselines with the actual files.
+2. Set the `TEST_UPDATE_BSL` to `1` (please refer to "Updating baselines in tests" section in this file) **and** run `ilverify.ps1` - this will automatically replace baselines. After that, please carefully review the change and push it to your branch if it makes sense.
 
 ## Automated Source Code Formatting
 

INTERNAL.md

@@ -38,7 +38,7 @@ their respective branches.
 
 [VS 16.1](https://dev.azure.com/devdiv/DevDiv/_release?definitionId=1669&_a=releases)
 
-VS 16.0 and prior were done manually
+VS 16.0 and prior were done manually.
 
 ## VS Insertions as part of the build definition
 
@@ -64,6 +64,7 @@ it's a good idea to check the previous link for any old or stalled insertions in
 Update the `insertTargetBranch` value at the bottom of `azure-pipelines.yml` in the appropriate release branch.  E.g., when VS 17.3 snapped and switched to ask mode, [this PR](/~https://github.com/dotnet/fsharp/pull/13456/files) correctly updates the insertion target so that future builds from that F# branch will get auto-inserted to VS.
 
 ### When VS `main` is open for insertions for preview releases of VS:
+
 0. Disable auto-merges from `main` to **current** release branch, please make a change for the following file and create a pull request:
 /~https://github.com/dotnet/roslyn-tools/blob/6d7c182c46f8319d7922561e2c1586c7aadce19e/src/GitHubCreateMergePRs/config.xml#L52-L74
 > You should comment out the `main -> release/devXX.X` flow until step #4 is completed (`<merge from="main" to="release/dev17.13" />`)
@@ -131,6 +132,23 @@ Since github issue filtering is currently not flexible enough, that query was ge
 Invoke-WebRequest -Uri "https://api.github.com/repos/dotnet/fsharp/labels?per_page=100" | ConvertFrom-Json | % { $_.name } | ? { $_.StartsWith("Area-") } | % { Write-Host -NoNewLine ('-label:"' + $_ + '" ') }
 ```
 
-## Other links
+## Fix problems with the internal source mirror
+
+The repo is [here](https://dev.azure.com/dnceng/internal/_git/dotnet-fsharp), the CI is [here](https://dnceng.visualstudio.com/internal/_build?definitionId=499).
+
+If something breaks in the CI there and you want to experiment, the general workflow is the following:
+1. Make a branch
+2. Make a change
+3. Run the build from your branch. If needed, set the "skipTests" variable to "true" - can save time at this stage.
+4. Once the problem and the fix is identified, make a PR to THIS (dotnet/fsharp) repo - it will propagate to the internal mirror just afterwards.
+5. Delete all your work in the internal repo.
+
+**DO NOT** try to push to the internal repo - this will mess up the flows. **DO NOT** create PRs to not confuse anyone.
+
+You need the following permissions to do the above investigations:
+- "Generic contribute"
+- "Create branch"
+- "Queue builds"
+- "Edit queue build configuration"
 
-[Internal source mirror](https://dev.azure.com/dnceng/internal/_git/dotnet-fsharp).
+If anything, reach out to the "First Responders" team.

azure-pipelines-PR.yml

@@ -229,7 +229,7 @@ stages:
             env:
               DOTNET_DbgEnableMiniDump: 1
               DOTNET_DbgMiniDumpType: 3 # Triage dump, 1 for mini, 2 for Heap, 3 for triage, 4 for full. Don't use 4 unless you know what you're doing.
-              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\$(_configuration)\$(Build.BuildId)-%e-%p-%t.dmp
+              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\Release\$(Build.BuildId)-%e-%p-%t.dmp
               NativeToolsOnMachine: true
             displayName: Build
 
@@ -247,8 +247,8 @@ stages:
             condition: failed()
             continueOnError: true
             inputs:
-                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\$(_configuration)'
-                ArtifactName: 'Windows $(_configuration) $(_testKind) process dumps'
+                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\Release'
+                ArtifactName: 'Windows Release WindowsLangVersionPreview process dumps'
                 ArtifactType: Container
                 parallel: true
 
@@ -269,7 +269,7 @@ stages:
             env:
               DOTNET_DbgEnableMiniDump: 1
               DOTNET_DbgMiniDumpType: 3 # Triage dump, 1 for mini, 2 for Heap, 3 for triage, 4 for full. Don't use 4 unless you know what you're doing.
-              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\$(_configuration)\$(Build.BuildId)-%e-%p-%t.dmp
+              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\Release\$(Build.BuildId)-%e-%p-%t.dmp
               NativeToolsOnMachine: true
             displayName: Build
 
@@ -287,8 +287,8 @@ stages:
             condition: failed()
             continueOnError: true
             inputs:
-                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\$(_configuration)'
-                ArtifactName: 'Windows $(_configuration) $(_testKind) process dumps'
+                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\Release'
+                ArtifactName: 'Windows Release WindowsNoRealsig_testCoreclr process dumps'
                 ArtifactType: Container
                 parallel: true
 
@@ -309,7 +309,7 @@ stages:
             env:
               DOTNET_DbgEnableMiniDump: 1
               DOTNET_DbgMiniDumpType: 3 # Triage dump, 1 for mini, 2 for Heap, 3 for triage, 4 for full. Don't use 4 unless you know what you're doing.
-              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\$(_configuration)\$(Build.BuildId)-%e-%p-%t.dmp
+              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\Release\$(Build.BuildId)-%e-%p-%t.dmp
               NativeToolsOnMachine: true
             displayName: Build
 
@@ -327,8 +327,8 @@ stages:
             condition: failed()
             continueOnError: true
             inputs:
-                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\$(_configuration)'
-                ArtifactName: 'Windows $(_configuration) $(_testKind) process dumps'
+                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\Release'
+                ArtifactName: 'Windows Release WindowsNoRealsig_testDesktop process dumps'
                 ArtifactType: Container
                 parallel: true
 
@@ -349,7 +349,7 @@ stages:
             env:
               DOTNET_DbgEnableMiniDump: 1
               DOTNET_DbgMiniDumpType: 3 # Triage dump, 1 for mini, 2 for Heap, 3 for triage, 4 for full. Don't use 4 unless you know what you're doing.
-              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\$(_configuration)\$(Build.BuildId)-%e-%p-%t.dmp
+              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\Release\$(Build.BuildId)-%e-%p-%t.dmp
               NativeToolsOnMachine: true
             displayName: Build
 
@@ -367,8 +367,8 @@ stages:
             condition: failed()
             continueOnError: true
             inputs:
-                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\$(_configuration)'
-                ArtifactName: 'Windows $(_configuration) $(_testKind) process dumps'
+                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\Release'
+                ArtifactName: 'Windows Release WindowsStrictIndentation process dumps'
                 ArtifactType: Container
                 parallel: true
 
@@ -385,7 +385,7 @@ stages:
             env:
               DOTNET_DbgEnableMiniDump: 1
               DOTNET_DbgMiniDumpType: 3 # Triage dump, 1 for mini, 2 for Heap, 3 for triage, 4 for full. Don't use 4 unless you know what you're doing.
-              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\$(_configuration)\$(Build.BuildId)-%e-%p-%t.dmp
+              DOTNET_DbgMiniDumpName: $(Build.SourcesDirectory)\artifacts\log\Release\$(Build.BuildId)-%e-%p-%t.dmp
               NativeToolsOnMachine: true
             displayName: Build
 
@@ -403,8 +403,8 @@ stages:
             condition: failed()
             continueOnError: true
             inputs:
-                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\$(_configuration)'
-                ArtifactName: 'Windows $(_configuration) $(_testKind) process dumps'
+                PathToPublish: '$(Build.SourcesDirectory)\artifacts\log\Release'
+                ArtifactName: 'Windows Release WindowsNoStrictIndentation process dumps'
                 ArtifactType: Container
                 parallel: true
 
@@ -825,6 +825,6 @@ stages:
               installationPath: $(Agent.ToolsDirectory)/dotnet
           - script: dotnet tool restore
             displayName: Restore dotnet tools
-          - pwsh: .\eng\ilverify.ps1
+          - pwsh: .\tests\ILVerify\ilverify.ps1
             displayName: Run ILVerify
             workingDirectory: $(Build.SourcesDirectory)

docs/release-notes/.FSharp.Core/9.0.200.md

@@ -1,6 +1,7 @@
 ### Fixed
 
 * Fix exception on Post after MailboxProcessor was disposed ([Issue #17849](/~https://github.com/dotnet/fsharp/issues/17849), [PR #17922](/~https://github.com/dotnet/fsharp/pull/17922))
+* Fix missing null annotation in Async.SwitchToContext ([Issue #18055](/~https://github.com/dotnet/fsharp/issues/18055), [PR #18059](/~https://github.com/dotnet/fsharp/pull/18059))
 
 ### Added
 

eng/Version.Details.xml

@@ -42,14 +42,14 @@
     </Dependency>
   </ProductDependencies>
   <ToolsetDependencies>
-    <Dependency Name="Microsoft.DotNet.Arcade.Sdk" Version="9.0.0-beta.24462.3">
+    <Dependency Name="Microsoft.DotNet.Arcade.Sdk" Version="9.0.0-beta.24572.2">
       <Uri>/~https://github.com/dotnet/arcade</Uri>
-      <Sha>91b9734abbad751d575c002b30778c88d978993c</Sha>
+      <Sha>b41381d5cd633471265e9cd72e933a7048e03062</Sha>
     </Dependency>
     <!-- Intermediate is necessary for source build. -->
-    <Dependency Name="Microsoft.SourceBuild.Intermediate.arcade" Version="9.0.0-beta.24462.3">
+    <Dependency Name="Microsoft.SourceBuild.Intermediate.arcade" Version="9.0.0-beta.24572.2">
       <Uri>/~https://github.com/dotnet/arcade</Uri>
-      <Sha>91b9734abbad751d575c002b30778c88d978993c</Sha>
+      <Sha>b41381d5cd633471265e9cd72e933a7048e03062</Sha>
       <SourceBuild RepoName="arcade" ManagedOnly="true" />
     </Dependency>
     <Dependency Name="optimization.windows_nt-x64.MIBC.Runtime" Version="1.0.0-prerelease.24462.2">