DoesNotReturn attribute can lead to CS0161

[PhilPJL]

If we have code like this:

using CommunityToolkit.Diagnostics;

namespace DoesNotReturnTest
{
    internal class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, World!");
        }

        int ThisFunctionMayNotReturnAndCausesACompilationError(int x)
        {
            if(x > 100) { return 99; }

            // This helper method is annotated with [DoesNotReturn] and I would expect the compiler to notice
            // but instead we get error CS0161 - not all code paths return a value
            ThrowHelper.ThrowArgumentOutOfRangeException(nameof(x));
        }

        int ThisFunctionMayNotReturnAndDoesNotCauseACompilationError(int x)
        {
            if (x > 100) { return 99; }

            throw new ArgumentOutOfRangeException(nameof(x));
        }
    }
}

It's my expectation that it will compile because the ThrowHelper methods are annotated with DoesNotReturn.
The two methods above are equivalent in my view. This behaviour makes the Community Toolkit's diagnostic throw helpers less useful than they might otherwise be.

I tried opening an issue https://developercommunity.visualstudio.com/t/The-DoesNotReturn-code-analysis-attrib/10495037?port=1025&fsid=99832d1c-2899-44ac-a4f0-88182ddfa0a9&ref=native&refTime=1697790182112&refUserId=7dbe2508-d94c-48bf-af55-63c2cfc609f9 against VS but this was rejected by the bot as a duplicate of https://developercommunity.visualstudio.com/t/DoesNotReturn-and-DoesNotReturnIf-is-not/10119245. @jaredpar says that this behaviour is 'by design'.

If we look at https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/attributes/nullable-analysis it explicitly says that DoesNotReturn is 'A method that never returns. In other words, it always throws an exception.'

If this is 'by design' then can we have an attribute that does tell the compiler that a method always throws an exception, as in JetBrains annotation AssertionMethod

[PhilPJL]

Closing now that I see that these attributes are only for nullability analysis. This is a shame.

[huoyaoyuan]

In short:

Nullability analysis is done as "best effort". It can have analysis holes like empty array of non-nullable type, so its result can bd incorrect.

In the other hand, the definite returning rule must be precised. The compiler must ensure the callee can't return in any path. It also need to be acknoledged by JIT so that the caller isn't treated as invalid code.