ulrichb/implicitnullability

Extends ReSharper's static nullability analysis by changing specific, configurable elements to be [NotNull] by default

implicitnullability's Issues

Implicit nullability for static readonly fields and properties

Static members are almost always not null, but the system types don't have proper external annotations, and JetBrains does not seem to fix this ever. (JetBrains/ExternalAnnotations#75, https://youtrack.jetbrains.com/issue/RSRP-464475, comments in https://www.jetbrains.com/help/resharper/Code_Analysis__External_Annotations.html)

Same applies to generated code (e.g. Settings.Default), which is assumed to be [CanBeNull] by implicit nullability, but in fact is [NotNull]

It would be a very helpful if static readonly fields and properties of external libraries and generated code would default to [NotNull] even if they have no annotations.

Cannot install plugin in Rider2017.3

I not see this plugin in plugins window.

Syntax Highlighting is Broken

First of all, thanks for your hard work on this! I think it is a pretty cool extension.

That being said, it doesn't appear to play well with ReSharper colored identifiers turned on and the vs2017 light theme. It did work prior to the Visual Studio 15.8 update though. All type names end up with the wrong color. I've tried reinstalling everything, resetting settings, etc. to no avail. Uninstalling this extension is the only thing that fixes it reliably.

With Extension Installed:

Without Extension Installed:

Use assembly/class level attribute to enable this with some level of granularity

As mentioned here:

https://youtrack.jetbrains.com/issue/RSRP-68137

Could be be opt-in at the class or assembly level via an attribute? This would then carry over in compiled builds.

Support for R# 2016.1

Now that it's RTM, I'd like to use this extension with 2016.1.

Any idea when it'll be updated?

Thanks!

ReSharper integration

Have you talked with JetBrains about integrating these features in ReSharper ?

support something that achieves the following Func<[NotNull]string>

As per my SO question here:
https://stackoverflow.com/questions/49247474/tell-resharper-that-a-funcstring-will-never-return-null

[NotNull]
private readonly Func<string> FunctionThatWillNeverBeNullNorReturnNull;

void Test(){
    string thisStringIsNotNull = FunctionThatWillNeverBeNullNorReturnNull();
}

Is it possible to tell resharper that the above function will never return null? Putting [NotNull] implies that the Function reference cannot be null, but I'm unsure how to tell resharper that what it returns won't be null either. Is this something you could support with your plugin?

Field nullability is checking backing fields for properties

Field nullability is showing warnings on instance and static constructors when the class has auto-properties defined.

class Foo
{
    public string Bar { get; set; }
    public Foo()
    {
        this.Bar = "";
    }
}

Field '<Bar>k__BackingField' marked with 'NotNull' attribute is not initialized on all execution paths

Incorrect behavior for Implicit nullability v4.9.0.13340193

public class Class
{
    public void Method1([CanBeNull] string value) => Echo(value); //Correct behavior
    public void Method2([CanBeNull] string value = null) => Echo(value); //Should warn "Possible 'null' assignment to entity with 'NotNull' attribute"
    private static void Echo(string value) => Console.WriteLine(value);
}

Bug for properties nullability

Hello! Thank you for your extension. I noticed that some functionality were broken. It's about properties nullability.
My version of extension: 4.2.0.11360173. My version of resharper: 2017.3.3

Selectively reverting to Resharper default nullability?

Hi,
thanks for this extension. I'm using it and enjoying the boilerplate reduction :)

One little issue: For generic data-structure-type things, e.g.

class Foo<T>
{
  public void AddItem(T t) { [...] }
  public T GetItem() { [...] }
}

, neither the implicit [NotNull] nor [CanBeNull] are optimal if the type is sometimes used with nullable items, and sometimes with items which must not be null.

If we leave AddItem and GetItem implicitly [NotNull], adding null items of course violates the contract, so there will be warnings, and checking the result of GetItem for null will cause specious "Condition is always false/true" and "code is heuristically unreachable" warnings. But if we make them [CanBeNull], there is an annoying warning whenever we use the result of GetItem, even if we know that this particular instance only contains non-nullable items.

I think Resharper's default "unknown" nullability is preferable in a case like this, so maybe there should be some attribute ([UnspecifiedNullability]?) to revert to that?

Of course, leaving the nullability unspecified is just sweeping the problem under the rug. A real solution would require "higher-order nullability", which I suppose is out-of-scope for this project and would have to go into Resharper itself. Something like:

[NullabilityParameter("N")]
class Foo<T>
{
  public void AddItem([Nullability("N")] T t) { [...] }

  [Nullability("N")]
  public T GetItem() { [...] }
}

void Something(
  [NullabilityArgument("N = NotNull")] Foo<string> foo1,
  [NullabilityArgument("N = CanBeNull")] Foo<string> foo2)
{
  foo1.Add(null); // Warning
  foo2.Add(null); // OK
}

(These are actually unrelated to generic type parameters; the example would make sense even if the item type of Foo was fixed to string)

Edit: Considering that non-nullable reference types might be coming to C# in the future, I guess it's not worth thinking about this too much.

Difference in behavior between explicit and implicit [NotNull]

Please see the following two images. In the first image, the parameter id is implicitly NotNull. ReSharper dims the null check and says it's unnecessary because id is never null. In the second image, I've added an explicit [NotNull] annotation and everything works as expected. I would expect the behavior to be the same in the two cases.

Assume NotNull for Inherited (Implemented) Members

I installed your extension and got some warnings right away. In this case it is from implementing an IList<> where it cannot determine the nullability of the members. Is there a way to mark these all as implicitly null?

Thanks for the cool project here!

Skip detection of XAML members or detect call to InitializeComponent

When working with XAML, it complains that class members (fields, in this case) defined in XAML (using x:Name) are not initialized on all excecution paths, even though InitializeComponent() is called in the constructor.

Is it possible to detect the call to InitializeComponent() or otherwise skip detection of XAML members?

"void" in "async void" detected as implicit/explicit NotNull

Handle Nullable<> in generic Methods

If I use the Nullable<T> (or T?) type, I implicitly state the possibility of null values, otherwise I would just use T.

This is detected correctly by the analyzer, so this works:

int? myInt;
void Allowed()
{
    myInt = new int?();
}

However, when I use T? as a generic argument for a method, the analyzer gets confused.

int? myInt;

T Forward<T>(T value)
{
    return value;
}

void Disallowed()
{
    // Possible 'null' assignment to entity marked with 'NotNull' attribute
    myInt = Forward(new int?());
}

I would have to mark my generic method accordingly:

int? myInt;

[CanBeNull] T Forward<T>([CanBeNull] T value)
{
    return value;
}

void Allowed()
{
    myInt = Forward(new int?());
}

However, I would then allow nullability for reference types using this method, which I do not want.

The analyzer should allow null arguments and null return values in generic methods, if they use a Nullable<> type.

Support R# 2019.1

Would be cool to have it already for the 2019.1 EAP, else we could not test it.

ImplicitNotNullConflictInHierarchy requires code duplication

It is assumed already by ReSharper that when interface/abstract/overriden method has [NotNull]/[CanBeNull] annotations then inheriting types should conform (and repeating attribute is grayed out as redundant).

So am I missing something or I should just disable this inspection?

AssemblyMetadata in .NET < 4.5?

I tried creating a .NET 4.0 project. Unfortunately, the AssemblyMetadata attribute does not seem to exist. Is there an alternative?

Integration into ReSharper CLT?

Sorry, I know this is the wrong place to ask this question but the JetBrains team was of little help.

I'm trying to integrate ImplicitNullability into our CI pipeline. Apparently, JetBrains removed the support for the /x extension argument. Here's what they say it should support:

(1) .nupkg auto-expansion: if a Nuget package (.nupkg ) file is found on startup in the product folder, it would be expanded automatically (into a shadow location), and its assemblies used with the product.

This means that a plugin .nupkg package could be put into the tool folder, and it will be loaded and used automatically.

This is doing absolutely nothing for me. I tried adding the ImplicitNullability.nupkg to the solution folder and all project folders but nothing is happening.

Have you tried this before? Do you have any idea whats going on?

Thank you for this fantastic library!

Implicit NotNull for properties

Is there a reason to not consider properties as NotNull implicitly? I have seen that you are adding support for fields, so why not properties?)

As Fody NullGuard also adds null checks for properties, it would be great to have the same behavior in order to be consistent between the static check and the runtime check.

Update for Resharper 2018.1

Could this be updated to work with Resharper 2018.1?

Support for "Nullable reference types"

If I install "Nullable reference types" preview resharper gives me lots of errors as it doesn't support this addition yet.

Does your plugin fix this and allow this code to not throw a warning?

string? canBeNull = null;

ReSharper 2017.1

ReSharper 2017.1 was released a few seconds ago. Please update A$AP.

Rider plugin doesn't show errors when expression is more complex

Hi,
thanks a lot for work on this extension!

I'm trying it both in VS/R# and Rider.
I've noticed a following difference between those two:

In VS/R#, following code correctly shows one error inBar(null):

[CanBeNull]
private static string Bar(string o) => null;
private static string Foo() => Bar(null).ToString();

In Rider it doesn't:

If I remove the .ToString() bit, it will show error in Bar(null):

But as soon as I remove the ; sign, the error will disappear, as if there was some condition that was only being checked on a top level of the expression on right hand side:

This all works in VS.