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

Missing CS8602 for calculated property #74057

Closed
eugene-rw opened this issue Jun 19, 2024 · 6 comments
Closed

Missing CS8602 for calculated property #74057

eugene-rw opened this issue Jun 19, 2024 · 6 comments
Labels
Area-Compilers Question Resolution-By Design The behavior reported in the issue matches the current design

Comments

@eugene-rw
Copy link

eugene-rw commented Jun 19, 2024

Version Used:8.0.302, 8.0.101

Steps to Reproduce:

call dotnet build for code

using System;
using System.Collections.Generic;

#nullable enable

class ValueProvider
{
    private int _counter;

    public List<double>? NumberList
    {
        get
        {
            if (_counter++ == 0)
                return new List<double>();

            return null;
        }
    }
}

class Program
{
    static void Main()
    {
        var provider = new ValueProvider();

        if (provider.NumberList != null)
        {
            var a = provider.NumberList;

            if (a.Count == 0)
            {
                Console.WriteLine("Success");
            }
        }
    }
}

Expected Behavior:
Warning CS8602

Actual Behavior:
No warning

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Jun 19, 2024
@eugene-rw
Copy link
Author

It seems, compiler incorrectly use condition "provider.NumberList != null" as proof of non-nullability of a

@huoyaoyuan
Copy link
Member

It seems, compiler incorrectly use condition "provider.NumberList != null" as proof of non-nullability of a

It is the contract of property. Nullability analysis and many other analyzers doesn't expect the get result of property to change randomly. There are also other cases that tooling can invoke the getter of properties.

@eugene-rw
Copy link
Author

@huoyaoyuan
I would agree, if it was simple variable. But nullability analysis can see that the property is function indeed, and doesn't relay on it constancy. It can be make as configurable though.

@huoyaoyuan
Copy link
Member

But nullability analysis can see that the property is function indeed

Nullability analysis and potentially all language features doesn't see through method body of other methods. It only check for the signatures with attributes applied.

It's also impractical to understand what can happen in a method in detail.

I would agree, if it was simple variable.

It's the contract of properties to act similar to simple variables. Many of the tooling including debugger follow this contract.

@eugene-rw
Copy link
Author

eugene-rw commented Jun 19, 2024

It's also impractical to understand what can happen in a method in detail.

Yes, of course.

I supposed, that there is a simple method to distinguish cases when property has simple get accessor with hidden backing field and when property calls function. But PropertyInfo has no info for that, it seems, that it can be compiler internals only.

@CyrusNajmabadi CyrusNajmabadi closed this as not planned Won't fix, can't repro, duplicate, stale Jun 19, 2024
@CyrusNajmabadi
Copy link
Member

Closing as by design. Only the signatures of members are examined to determine their impact on NRT analysis.

@CyrusNajmabadi CyrusNajmabadi added Question Resolution-By Design The behavior reported in the issue matches the current design and removed untriaged Issues and PRs which have not yet been triaged by a lead labels Jun 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Question Resolution-By Design The behavior reported in the issue matches the current design
Projects
None yet
Development

No branches or pull requests

3 participants