Fix binding of `nameof` of `Color Color` by jjonescz · Pull Request #82477 · dotnet/roslyn

jjonescz · 2026-02-20T13:37:17Z

AlekseyTs · 2026-02-20T14:55:30Z

src/Compilers/CSharp/Portable/Binder/Binder_Invocation.cs

                    }
                }

+                bool useType = !Compilation.IsFeatureEnabled(MessageID.IDS_FeatureInstanceMemberInNameof);


bool useType = !Compilation.IsFeatureEnabled(MessageID.IDS_FeatureInstanceMemberInNameof);

Is there an observable difference from this check? I cannot tell from the added tests. #Closed

What is the behavior for the test scenarios when the feature is not enabled?

Yes, without this we would bind always as value, not type, which would result in langversion error for IDS_FeatureInstanceMemberInNameof in C# 11 or lower, but since we pass BindingDiagnosticsBag.Discarded below, the error would be surfaced as "Unable to determine specific cause of the failure." during emit.

In other words, without this change, the tests would fail with unexpected diagnostic "Unable to determine specific cause of the failure." in C# 11.

the error would be surfaced as "Unable to determine specific cause of the failure." during emit.

Because?

Because the node would have HasErrors = true, those errors wouldn't be in any diagnostics bag, but methodCompiler._globalHasErrors would be true, hitting this:

roslyn/src/Compilers/CSharp/Portable/Compiler/MethodCompiler.cs

Lines 199 to 208 in 42e9b92

// If we are trying to emit and there's an error without a corresponding diagnostic (e.g. because

// we depend on an invalid type or constant from another module), then explicitly add a diagnostic.

// This diagnostic is not very helpful to the user, but it will prevent us from emitting an invalid

// module or crashing.

if (moduleBeingBuiltOpt != null && (methodCompiler._globalHasErrors || moduleBeingBuiltOpt.SourceModule.HasBadAttributes) && !diagnostics.HasAnyErrors() && !hasDeclarationErrors)

{

var messageResourceName = methodCompiler._globalHasErrors ? nameof(CodeAnalysisResources.UnableToDetermineSpecificCauseOfFailure) : nameof(CodeAnalysisResources.ModuleHasInvalidAttributes);

diagnostics.Add(ErrorCode.ERR_ModuleEmitFailure, NoLocation.Singleton, ((Cci.INamedEntity)moduleBeingBuiltOpt).Name!,

new LocalizableResourceString(messageResourceName, CodeAnalysisResources.ResourceManager, typeof(CodeAnalysisResources)));

}

AlekseyTs · 2026-02-20T14:57:57Z

Done with review pass (commit 1)

AlekseyTs · 2026-02-20T15:18:09Z

src/Compilers/CSharp/Portable/Binder/Binder_Invocation.cs

                    methodGroup.Flags,
                    methodGroup.FunctionType,
-                    receiverOpt: ReplaceTypeOrValueReceiver(methodGroup.ReceiverOpt, useType: false, BindingDiagnosticBag.Discarded), //only change
+                    receiverOpt: ReplaceTypeOrValueReceiver(methodGroup.ReceiverOpt, useType: useType, BindingDiagnosticBag.Discarded), //only change


useType

Could you please investigate how TypeOValueReceiver was handled for the problematic scenario prior to #80978? #Closed

I assume it remained in the tree, but was never used during emit or lowering. Is this correct?

That is correct, BoundTypeOrValueExpression node remained in the tree.

AlekseyTs · 2026-02-20T15:53:10Z

src/Compilers/CSharp/Test/Semantic/Semantics/NameOfTests.cs

+                }
+                class D
+                {
+                    public void M() { }


public void M() { }

Consider also testing with static member

AlekseyTs · 2026-02-20T16:00:26Z

src/Compilers/CSharp/Portable/Binder/Binder_Invocation.cs

                    methodGroup.Flags,
                    methodGroup.FunctionType,
-                    receiverOpt: ReplaceTypeOrValueReceiver(methodGroup.ReceiverOpt, useType: false, BindingDiagnosticBag.Discarded), //only change
+                    receiverOpt: ReplaceTypeOrValueReceiver(methodGroup.ReceiverOpt, useType: useType, BindingDiagnosticBag.Discarded), //only change


useType

Can we always pass true here?

AlekseyTs · 2026-02-20T16:05:29Z

src/Compilers/CSharp/Portable/Binder/Binder_Invocation.cs

                    methodGroup.Flags,
                    methodGroup.FunctionType,
-                    receiverOpt: ReplaceTypeOrValueReceiver(methodGroup.ReceiverOpt, useType: false, BindingDiagnosticBag.Discarded), //only change
+                    receiverOpt: ReplaceTypeOrValueReceiver(methodGroup.ReceiverOpt, useType: useType, BindingDiagnosticBag.Discarded), //only change


BindingDiagnosticBag.Discarded

It looks like always discarding diagnostics here is fragile. We should try switching to boundArgument.HasAnyErrors ? BindingDiagnosticBag.Discarded : diagnostics. Also, please check other call sites of this helper that unconditionally discard diagnostics when we are not in an obvious error recovery mode. We might want to take a close look at those and quite possibly adjust as well. Also, please review other changes in #80978 that unconditionally discard diagnostics.

AlekseyTs · 2026-02-20T16:06:48Z

Done with review pass (commit 1)

Fix binding of nameof of Color Color

5bf1014

jjonescz requested a review from AlekseyTs February 20, 2026 13:37

github-actions bot added the Area-Compilers label Feb 20, 2026

AlekseyTs reviewed Feb 20, 2026

View reviewed changes

jjonescz marked this pull request as ready for review February 20, 2026 15:50

jjonescz requested a review from a team as a code owner February 20, 2026 15:50

AlekseyTs reviewed Feb 20, 2026

View reviewed changes

jjonescz added 2 commits February 20, 2026 17:03

Test static member too

a3e9dc0

Simplify by always binding as type

09b517d

AlekseyTs reviewed Feb 20, 2026

View reviewed changes

Avoid discarding diagnostics

be85c08

	// If we are trying to emit and there's an error without a corresponding diagnostic (e.g. because
	// we depend on an invalid type or constant from another module), then explicitly add a diagnostic.
	// This diagnostic is not very helpful to the user, but it will prevent us from emitting an invalid
	// module or crashing.
	if (moduleBeingBuiltOpt != null && (methodCompiler._globalHasErrors \|\| moduleBeingBuiltOpt.SourceModule.HasBadAttributes) && !diagnostics.HasAnyErrors() && !hasDeclarationErrors)
	{
	var messageResourceName = methodCompiler._globalHasErrors ? nameof(CodeAnalysisResources.UnableToDetermineSpecificCauseOfFailure) : nameof(CodeAnalysisResources.ModuleHasInvalidAttributes);
	diagnostics.Add(ErrorCode.ERR_ModuleEmitFailure, NoLocation.Singleton, ((Cci.INamedEntity)moduleBeingBuiltOpt).Name!,
	new LocalizableResourceString(messageResourceName, CodeAnalysisResources.ResourceManager, typeof(CodeAnalysisResources)));
	}

Comments

Conversation

jjonescz commented Feb 20, 2026

Uh oh!

AlekseyTs Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jjonescz Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs commented Feb 20, 2026

Uh oh!

AlekseyTs Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlekseyTs commented Feb 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

AlekseyTs Feb 20, 2026 •

edited

Loading

jjonescz Feb 20, 2026 •

edited

Loading

AlekseyTs Feb 20, 2026 •

edited

Loading