compiler: Exclude false scope members from encoded name duplication tracking (#8681)

This is a very strange bug that likely stems from the way mutators work.

When mutating a model for visibility transforms, we create clones of the
model's properties. These clones end up checked/finished, even if they
are not actually _attached_ to the model, and vice versa (the original
properties may be checked/finished even if the clone ends up attached).

This runs stateful decorators, like `@encodedName`. Unfortunately, in
these cases, it means that both the clone and the original property end
up binding an encoded name within the same scope, which the validator
later sees as a conflict.

However, only one of these properties is actually a member of the scope
at validation time. This PR uses that to exclude "false members". These
are properties that exist in the state map (the decorator has been
applied to them), but aren't actually bound to the parent they claim to
be a member of. We can work around this mutator bug in the validator by
checking if the target is actually within the set of member values (in
this case, the properties actually present in the parent model, but this
will also work for enum members and union variants).

Closes #8599

Author: witemple-msft

.chronus/changes/witemple-msft-fix-encodedname-dup-detect-2025-9-7-15-21-36.md

@@ -0,0 +1,7 @@
+---
+changeKind: fix
+packages:
+  - "@typespec/compiler"
+---
+
+Addressed a bug that could cause duplicate `@encodedName` applications to be detected when none actually exist.

packages/compiler/src/lib/encoded-names.ts

@@ -106,7 +106,16 @@ export function validateEncodedNamesConflicts(program: Program) {
 
   for (const [target, map] of getEncodedNamesStateMap(program).entries()) {
     const scope = getScope(target);
-    if (scope === undefined) {
+    const memberValues = new Set(scope?.members.values());
+    if (
+      scope === undefined ||
+      // Workaround: exclude members that aren't actually in the scope. This can happen when types of
+      // properties, enum members, or union variants are cloned for one reason or another, but are not
+      // actually attached to the parent type. This should probably be fixed in cloning logic (mutator
+      // implementation) instead, but for now this workaround solves some problems with false positives
+      // in duplication tracking here.
+      !memberValues.has(target)
+    ) {
       return;
     }
     for (const [mimeType, name] of map.entries()) {

packages/compiler/src/lib/visibility.ts

@@ -681,7 +681,7 @@ function createVisibilityFilterMutator(
             realm.remove(clone);
             modified = true;
           } else {
-            const mutated = mutateSubgraph(program, [mpMutator], prop);
+            const mutated = cachedMutateSubgraph(program, mpMutator, prop);
 
             clone.properties.set(key, mutated.type as ModelProperty);
 

packages/compiler/test/visibility.test.ts

@@ -1239,6 +1239,20 @@ describe("compiler: visibility core", () => {
     ok(arrA.properties.has("a"));
     ok(!arrA.properties.has("invisible"));
   });
+
+  it("does not duplicate encodedName metadata", async () => {
+    const diagnostics = await runner.diagnose(`
+      model SomeModel {
+        @visibility(Lifecycle.Read)
+        @encodedName("application/json", "some_other_name")
+        someOtherName: string;
+      }
+
+      alias ReadModel = Read<SomeModel>;
+    `);
+
+    expectDiagnosticEmpty(diagnostics);
+  });
 });
 
 function validateCreateOrUpdateTransform(