Version Used:
Visual Studio 2019 Preview 16.0.0 Preview 1.1
(it had Resharper 2018.3 installed but the code analysis was off at the time)
Steps to Reproduce:
int when constructing an instance of a type e.g. throw new InvalidEnumArgumentException(nameof(enumInstance), (int) enumInstance, typeof(SomeEnumType));Full code used in testing:
using System;
using System.Collections.Generic;
using System.ComponentModel;
namespace RedundantCastTesting
{
class Program
{
static void Main(string[] args)
{
Alphabet enumInstance = (Alphabet) 110;
//Dictionary initialiser; False positives. Initially reported in #29264, Resolved in #30245
Dictionary<int, string> someDictionary = new Dictionary<int, string>()
{
[(int)Alphabet.A] = "This is A",
[(int)Alphabet.B] = "This is B"
};
//Array initialiser; Working as expected
int[] integers = {(int)Alphabet.A, (int)Alphabet.B};
//Constructor parameter; False positives
if (!Enum.IsDefined(typeof(Alphabet), enumInstance))
throw new InvalidEnumArgumentException(nameof(enumInstance), (int) enumInstance, typeof(Alphabet));
IntegerWrapper instance = new IntegerWrapper((int)enumInstance);
//Accessing indexer; working as expected
someDictionary[(int) Alphabet.A] = "This maybe isn't A (Just kidding)";
string someString = someDictionary[(int) Alphabet.B];
//Method parameter; working as expected
SomeMethodWithIntParameter("Random string", (int) enumInstance);
}
static void SomeMethodWithIntParameter(string someString, int someParameter)
{
Console.WriteLine(someParameter.ToString());
return;
}
class IntegerWrapper
{
public int Value { get; set; }
public IntegerWrapper(int value)
{
Value = value;
}
}
enum Alphabet
{
A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z
}
}
}
Expected Behavior:
No suggestions should be made (Removing the cast will result in CS1503)
Actual Behavior:
A suggestion is made (IDE0004: Cast is redundant) when passing the cast enum instance as a parameter to type constructors.

This does not occur when using VS2017 Community 15.9.4.
It seems to be somewhat related to #29264 (Which had been resolved in #30245), but I don't see this case being tested against. Could anyone confirm that this is fixed in #30245 or not?
resolved via https://github.com/dotnet/roslyn/pull/32467
Most helpful comment
resolved via https://github.com/dotnet/roslyn/pull/32467