Skip to content
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

Nullness issue - No way to silence warning in e.g. ServiceCollection.AddSingleton if type allows null #18021

Open
2 of 7 tasks
cmeeren opened this issue Nov 17, 2024 · 1 comment
Labels
Area-Nullness Issues related to handling of Nullable Reference Types Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code.
Milestone

Comments

@cmeeren
Copy link
Contributor

cmeeren commented Nov 17, 2024

Issue description

Consider this code as a placeholder for a type defined in an external library:

[<AllowNullLiteral>]
type IInterfaceFromExternalPackage = interface end

[<AllowNullLiteral>]
type ImplementorFromExternalPackage() =
    interface IInterfaceFromExternalPackage

Now consider the following:

open Microsoft.Extensions.DependencyInjection

ServiceCollection().AddSingleton<IInterfaceFromExternalPackage>(ImplementorFromExternalPackage())

This causes a compiler warning:

FS3261 : Nullness warning: The type 'IInterfaceFromExternalPackage' supports 'null' but a non-null type is expected.

Of course, there is no actual nullness issue here since I pass a non-null (singleton) instance of the type. However, I can find no way of silencing this warning apart from disabling it entirely for the file.

Choose one 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 annotations).
  • C#/F# interop issue related to nullness metadata.
  • Other (none of the categories above apply).

Operating System

Windows (Default)

What .NET runtime/SDK kind are you seeing the issue on

.NET SDK (.NET Core, .NET 5+)

.NET Runtime/SDK version

.NET SDK 9.0.100

Reproducible code snippet and actual behavior

No response

Possible workarounds

No response

@cmeeren cmeeren added Area-Nullness Issues related to handling of Nullable Reference Types Bug Needs-Triage labels Nov 17, 2024
@github-actions github-actions bot added this to the Backlog milestone Nov 17, 2024
@T-Gro
Copy link
Member

T-Gro commented Nov 18, 2024

The interplay of [<AllowNullLiteral>] is not good here and the recommendation definitely is to migrate away from it towards nullable annotations.
However, I do understand the case of having a type defined elsewhere and not being able to change it.

If only the implementing type supports null but not the interface, you could do:
let singleton:IInterfaceFromExternalPackage = ImplementorFromExternalPackage()

If the interface type itself supports null, the warning will still be raised for generic code with T:not null constraint.
For now, ignoring the warning will indeed remain the only option.

@T-Gro T-Gro removed their assignment Nov 18, 2024
@abonie abonie added Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code. and removed Needs-Triage labels Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Nullness Issues related to handling of Nullable Reference Types Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code.
Projects
Status: New
Development

No branches or pull requests

3 participants