PreferBuiltInOrFrameworkTypeDiagnosticId is used in two analyzers

[Youssef1313]

Why is this needed here? there is already a separate analyzer for this:

roslyn/src/Features/Core/Portable/PreferFrameworkType/PreferFrameworkTypeDiagnosticAnalyzerBase.cs

Line 12 in d57cddb

internal abstract class PreferFrameworkTypeDiagnosticAnalyzerBase<TSyntaxKind, TExpressionSyntax, TPredefinedTypeSyntax> :

Both are even using the same ID.

Originally posted by @Youssef1313 in #50305 (comment)

[Youssef1313]

Tagging @CyrusNajmabadi

[CyrusNajmabadi]

I'm honestly not undestanding the question.

[Youssef1313]

@CyrusNajmabadi The same diagnostic id is used in two different analyzers: SimplifyTypeNames and PreferFrameworkType

roslyn/src/Features/Core/Portable/SimplifyTypeNames/SimplifyTypeNamesDiagnosticAnalyzerBase.cs

Lines 59 to 66 in 20cd3aa

	private static readonly DiagnosticDescriptor s_descriptorPreferBuiltinOrFrameworkType = new(IDEDiagnosticIds.PreferBuiltInOrFrameworkTypeDiagnosticId,
	s_localizableTitleSimplifyNames,
	s_localizableMessage,
	DiagnosticCategory.Style,
	DiagnosticSeverity.Hidden,
	isEnabledByDefault: true,
	helpLinkUri: DiagnosticHelper.GetHelpLinkForDiagnosticId(IDEDiagnosticIds.PreferBuiltInOrFrameworkTypeDiagnosticId),
	customTags: DiagnosticCustomTags.Unnecessary.Concat(EnforceOnBuildValues.PreferBuiltInOrFrameworkType.ToCustomTag()).ToArray());

roslyn/src/Features/Core/Portable/PreferFrameworkType/PreferFrameworkTypeDiagnosticAnalyzerBase.cs

Lines 12 to 25 in 20cd3aa

	internal abstract class PreferFrameworkTypeDiagnosticAnalyzerBase<TSyntaxKind, TExpressionSyntax, TPredefinedTypeSyntax> :
	AbstractBuiltInCodeStyleDiagnosticAnalyzer
	where TSyntaxKind : struct
	where TExpressionSyntax : SyntaxNode
	where TPredefinedTypeSyntax : TExpressionSyntax
	{
	protected PreferFrameworkTypeDiagnosticAnalyzerBase()
	: base(IDEDiagnosticIds.PreferBuiltInOrFrameworkTypeDiagnosticId,
	EnforceOnBuildValues.PreferBuiltInOrFrameworkType,
	options: ImmutableHashSet.Create<IPerLanguageOption>(CodeStyleOptions2.PreferIntrinsicPredefinedTypeKeywordInDeclaration, CodeStyleOptions2.PreferIntrinsicPredefinedTypeKeywordInMemberAccess),
	new LocalizableResourceString(nameof(FeaturesResources.Use_framework_type), FeaturesResources.ResourceManager, typeof(FeaturesResources)),
	new LocalizableResourceString(nameof(FeaturesResources.Use_framework_type), FeaturesResources.ResourceManager, typeof(FeaturesResources)))
	{
	}

Shouldn't only the PreferFrameworkType analyzer be responsible for reporting IDE0049?

[CyrusNajmabadi]

Seems reasonable. What happens if you make that change?

[Youssef1313]

Seems reasonable. What happens if you make that change?

I haven't yet tried. I'll try to give a look soon.

[Youssef1313]

Not a bug, sorry!

One analyzer goes from framework types to built-in, and the other goes in the opposite direction. Closing out.
Sorry for the mis-information