From 9d587d706af349bbb3aa2fed967868f91e067a5b Mon Sep 17 00:00:00 2001 From: Tomas Grosup Date: Thu, 27 Jun 2024 16:50:42 +0200 Subject: [PATCH 1/4] Create template for nullness related issues --- .github/ISSUE_TEMPLATE/nullness_issue.md | 44 ++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/nullness_issue.md diff --git a/.github/ISSUE_TEMPLATE/nullness_issue.md b/.github/ISSUE_TEMPLATE/nullness_issue.md new file mode 100644 index 00000000000..5dd0a1194b3 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/nullness_issue.md @@ -0,0 +1,44 @@ +--- +name: Nullness-related report +about: Create a report related to nullable reference types handling +title: '' +labels: [Bug, Needs-Triage,Area-Nullness] +assignees: 'T-Gro' + +--- + + +Please check at [Nullable Reference Types RFC](https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1060-nullable-reference-types.md) if this issue isn't a known limitation, such as missing flow-control analysis after branching constructs like `if` or `while`. +Please provide a succinct description of the issue and choose 1 or more from the following categories of impact + +- [ ] Unexpected nullness warning (false positive in nullness checking, code uses --checknulls and langversion:preview) +- [ ] Missing nullness warning in a case which can produce nulls (false negative, code uses --checknulls and langversion:preview) +- [ ] Breaking change related to older `null` constructs in code not using the checknulls switch +- [ ] Breaking change related to generic code and explicit type constraints (`null`, `not null`) +- [ ] Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotatins) +- [ ] C#/F# interop issue related to nullness metadata +- [ ] None of the categories above apply + +**Reproducible code snippet** + +Provide a small code snippet demonstrating the issue. +If referenced code is needed for the repro and cannot be shared (e.g. a private C# nuget package), try to share at least the metadata annotations from the called type+member as seen in `ilspy.exe`. C# compiler produces attributes like `[Nullable]` and `[NullableContext]`, which is what F# compiler tries to load and interpret in C#/F# interop scenarios. + + +**Expected behavior** +(if not clear from category selection above) + +**Actual behavior** +(if not clear from category selection above) + +**Known workarounds** + +Are there any language constructs (typically pattern matching, library constructs, Null/NonNull active patterns, explicit type annotations) allowing the same logic be expressed differently in order to mitigate the experienced nullness issue? + +**Related information** + +Provide any related information (optional): + +* Operating system +* .NET Runtime kind (.NET Core, .NET Framework, Mono) +* Editing Tools (e.g. Visual Studio Version, Visual Studio) From df89da83a79dd817b323c82d64457ce348fa0ff9 Mon Sep 17 00:00:00 2001 From: Tomas Grosup Date: Mon, 1 Jul 2024 15:15:45 +0200 Subject: [PATCH 2/4] Change form to use .yml --- .github/ISSUE_TEMPLATE/nullness_issue.md | 44 ------------- .github/ISSUE_TEMPLATE/nullness_issue.yml | 76 +++++++++++++++++++++++ 2 files changed, 76 insertions(+), 44 deletions(-) delete mode 100644 .github/ISSUE_TEMPLATE/nullness_issue.md create mode 100644 .github/ISSUE_TEMPLATE/nullness_issue.yml diff --git a/.github/ISSUE_TEMPLATE/nullness_issue.md b/.github/ISSUE_TEMPLATE/nullness_issue.md deleted file mode 100644 index 5dd0a1194b3..00000000000 --- a/.github/ISSUE_TEMPLATE/nullness_issue.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -name: Nullness-related report -about: Create a report related to nullable reference types handling -title: '' -labels: [Bug, Needs-Triage,Area-Nullness] -assignees: 'T-Gro' - ---- - - -Please check at [Nullable Reference Types RFC](https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1060-nullable-reference-types.md) if this issue isn't a known limitation, such as missing flow-control analysis after branching constructs like `if` or `while`. -Please provide a succinct description of the issue and choose 1 or more from the following categories of impact - -- [ ] Unexpected nullness warning (false positive in nullness checking, code uses --checknulls and langversion:preview) -- [ ] Missing nullness warning in a case which can produce nulls (false negative, code uses --checknulls and langversion:preview) -- [ ] Breaking change related to older `null` constructs in code not using the checknulls switch -- [ ] Breaking change related to generic code and explicit type constraints (`null`, `not null`) -- [ ] Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotatins) -- [ ] C#/F# interop issue related to nullness metadata -- [ ] None of the categories above apply - -**Reproducible code snippet** - -Provide a small code snippet demonstrating the issue. -If referenced code is needed for the repro and cannot be shared (e.g. a private C# nuget package), try to share at least the metadata annotations from the called type+member as seen in `ilspy.exe`. C# compiler produces attributes like `[Nullable]` and `[NullableContext]`, which is what F# compiler tries to load and interpret in C#/F# interop scenarios. - - -**Expected behavior** -(if not clear from category selection above) - -**Actual behavior** -(if not clear from category selection above) - -**Known workarounds** - -Are there any language constructs (typically pattern matching, library constructs, Null/NonNull active patterns, explicit type annotations) allowing the same logic be expressed differently in order to mitigate the experienced nullness issue? - -**Related information** - -Provide any related information (optional): - -* Operating system -* .NET Runtime kind (.NET Core, .NET Framework, Mono) -* Editing Tools (e.g. Visual Studio Version, Visual Studio) diff --git a/.github/ISSUE_TEMPLATE/nullness_issue.yml b/.github/ISSUE_TEMPLATE/nullness_issue.yml new file mode 100644 index 00000000000..9f387387b20 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/nullness_issue.yml @@ -0,0 +1,76 @@ +name: Nullness-related report +title: 'Nullness issue - ....' +description: Create a report related to nullable reference types handling +labels: [Bug, Needs-Triage,Area-Nullness] +assignees: 'T-Gro' +body: + - type: textarea + attributes: + label: Issue description + description: A concise description of what you're experiencing. + validations: + required: true + - type: markdown + attributes: + value: | + Please check at [Nullable Reference Types RFC](https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1060-nullable-reference-types.md) if this issue isn't a known limitation, such as missing flow-control analysis after branching constructs like `if` or `while`. Also check at [existing nullness issues](https://github.com/dotnet/fsharp/issues?q=is%3Aissue+label%3AArea-Nullness+) if it hasn't been reported already. + Please provide a succinct description of the issue and choose 1 or more from the following categories of impact + - type: checkboxes + id: categories + attributes: + label: Choose one or more from the following categories of impact + options: + - label: Unexpected nullness warning (false positive in nullness checking, code uses --checknulls and langversion:preview). + - label: Missing nullness warning in a case which can produce nulls (false negative, code uses --checknulls and langversion:preview). + - label: Breaking change related to older `null` constructs in code not using the checknulls switch. + - label: Breaking change related to generic code and explicit type constraints (`null`, `not null`). + - label: Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotatins). + - label: C#/F# interop issue related to nullness metadata. + - label: Other (none of the categories above apply). + validations: + required: true + - type: dropdown + id: os + attributes: + label: Operating System + description: What operating system are you running? + options: + - Windows (Default) + - Linux + - macOS + default: 0 + validations: + required: true + - type: dropdown + id: dotnet-kind + attributes: + label: What .NET runtime/SDK kind are you seeing the issue on + multiple: false + options: + - .NET SDK (.NET Core, .NET 5+) + - .NET Framework + default: 0 + validations: + required: true + - type: input + id: dotnet-version + attributes: + label: .NET Runtime/SDK version + placeholder: e.g. .NET 9 or .NET SDK 9.0.100 + - type: textarea + attributes: + label: Reproducible code snippet and actual behavior + description: | + Provide a small code snippet demonstrating the issue. | + If referenced code is needed for the repro and cannot be shared (e.g. a private C# nuget package), try to share at least the metadata annotations from the called type+member as seen in `ilspy.exe`. C# compiler produces attributes like `[Nullable]` and `[NullableContext]`, which is what F# compiler tries to load and interpret in C#/F# interop scenarios. + value: Code snippet + validations: + required: false + - type: textarea + attributes: + label: Possible workarounds + description: | + Are there any language constructs (typically pattern matching, library constructs, Null/NonNull active patterns, explicit type annotations) allowing the same logic be expressed differently in order to mitigate the experienced nullness issue? + value: Possible workaround + validations: + required: false \ No newline at end of file From 555047863e5accae41f62a3232d0612b31fd2d02 Mon Sep 17 00:00:00 2001 From: Tomas Grosup Date: Mon, 1 Jul 2024 15:22:07 +0200 Subject: [PATCH 3/4] Value -> placeholder --- .github/ISSUE_TEMPLATE/nullness_issue.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/nullness_issue.yml b/.github/ISSUE_TEMPLATE/nullness_issue.yml index 9f387387b20..da81cc3e4ed 100644 --- a/.github/ISSUE_TEMPLATE/nullness_issue.yml +++ b/.github/ISSUE_TEMPLATE/nullness_issue.yml @@ -63,7 +63,7 @@ body: description: | Provide a small code snippet demonstrating the issue. | If referenced code is needed for the repro and cannot be shared (e.g. a private C# nuget package), try to share at least the metadata annotations from the called type+member as seen in `ilspy.exe`. C# compiler produces attributes like `[Nullable]` and `[NullableContext]`, which is what F# compiler tries to load and interpret in C#/F# interop scenarios. - value: Code snippet + placeholder: Code snippet validations: required: false - type: textarea @@ -71,6 +71,6 @@ body: label: Possible workarounds description: | Are there any language constructs (typically pattern matching, library constructs, Null/NonNull active patterns, explicit type annotations) allowing the same logic be expressed differently in order to mitigate the experienced nullness issue? - value: Possible workaround + placeholder: Possible workaround validations: required: false \ No newline at end of file From 5c974952bdf6f68558d35483727dd474851c8202 Mon Sep 17 00:00:00 2001 From: Tomas Grosup Date: Mon, 1 Jul 2024 15:23:46 +0200 Subject: [PATCH 4/4] typo --- .github/ISSUE_TEMPLATE/nullness_issue.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/nullness_issue.yml b/.github/ISSUE_TEMPLATE/nullness_issue.yml index da81cc3e4ed..5d46cbdffae 100644 --- a/.github/ISSUE_TEMPLATE/nullness_issue.yml +++ b/.github/ISSUE_TEMPLATE/nullness_issue.yml @@ -24,7 +24,7 @@ body: - label: Missing nullness warning in a case which can produce nulls (false negative, code uses --checknulls and langversion:preview). - label: Breaking change related to older `null` constructs in code not using the checknulls switch. - label: Breaking change related to generic code and explicit type constraints (`null`, `not null`). - - label: Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotatins). + - label: Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotations). - label: C#/F# interop issue related to nullness metadata. - label: Other (none of the categories above apply). validations: