Generic struct specialization rejects valid associated-type equality constraint

[tangent-vector]

Summary

Specializing a generic struct can reject a valid equality constraint on an associated type, even
when the concrete conformance supplies exactly the required associated type.

This reproducer uses only user-space interfaces and types. It has no dependency on autodiff,
numeric interfaces, or builtin core-module conformances.

Reproducer

interface IHasElement
{
    associatedtype Element;
}

struct ConcreteElement {}

struct Container : IHasElement
{
    typealias Element = ConcreteElement;
}

struct RequiresConcreteElement<T : IHasElement>
    where T.Element == ConcreteElement
{}

RequiresConcreteElement<Container> value;

Compile with:

slangc repro.slang -target none

Expected behavior

The source compiles. Container conforms to IHasElement, and its witness explicitly defines
Container.Element as ConcreteElement, so the specialization satisfies
T.Element == ConcreteElement.

Actual behavior

error[E38029]: type argument doesn't conform to interface
  --> repro.slang:17:1
   |
17 | RequiresConcreteElement<Container> value;
   | ^^^^^^^^^^^^^^^^^^^^^^^ type argument 'Container.Element' does not conform to the required interface 'ConcreteElement'
---'

The diagnostic also describes one endpoint of a type equality as an interface, which obscures the
underlying failed equality check.

Scope and controls

• The failure does not depend on T.Element == T: an unrelated user-defined ConcreteElement on
  the right-hand side fails as shown above.
• Reversing the equality to ConcreteElement == T.Element does not change the result.
• Adding a second generic parameter U and writing where T.Element == U also fails when
  specializing with the matching concrete types.
• The equivalent constraint on a generic function successfully specializes for the same user
  types. The failing path therefore appears specific to validation or specialization of a generic
  type.

This appears related to #6714. That issue's nested generic-type reproducer was reported as no longer
reproducing at 996ebcbdc, but its original shape also produces E38029 with the compiler version
below. The smaller reproducer here shows that neither nesting nor array associated types are
required, so this may be a regression or a remaining generic-type specialization path not covered
by the earlier fix.

Version tested

2026.14.1-80-gd4c72aab0

[nv-slang-bot]

Triage summary (automated specialist triage; fix in progress)

• Status: Reproduced on top-of-tree (v2026.16-43-gab5db6cf5, newer than the reported 2026.14.1-80). All four of your scope/controls confirmed (reversed equality, second param U, generic-function specializes fine, no nesting/array required). Classified bug / high / P1, component frontend semantic checker (generics/type-system); Issue Type set to Bug (existing regression / Typesystem / reproduced labels left as-is).
• Link: Triaged → handed to the fixer; fix incoming.
• Verdict: The spurious E38029 is emitted by an equality-blind linear constraint pass (slang-check-overload.cpp:1260-1310), but that is a symptom, not the root cause. An isolation matrix shows the real discriminator is scope, not equality: R<Container> is rejected at module scope (global var, struct field, typealias, function parameter/return) yet compiles fine as a local variable inside a function body — and the conformance variant where T.Element : IMarker fails identically at module scope. Root cause: the associated-type projection Container.Element is not reduced to its concrete witness type when a generic type application is validated at module/header scope, so the equality-aware worklist solver that succeeds in a function body falls through to the blind pass. (where T.Element == T.Element, where T == ConcreteElement, and where T.Element == U.Element all compile — reflexive/non-projection cases don't need the reduction.)
• Next-action: Fixer to root-cause the module-scope projection reduction / solver readiness (recommended), optionally also equality-gating the diagnostic sites for correct wording. Likely resolves the closely-related Valid where clause can fail to validate when using associatedtype generics #6714 as well. Merge stays maintainer-gated.
• Blocker: None.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[nv-slang-bot]

Fix in draft PR #12827.

• Status: Fixed — draft PR Fix #12822: reduce associated-type projection in where-clause at module scope #12827 open against master, verified at HEAD.
• Root cause: At module/header scope the associated-type projection Container.Element is not reduced to its satisfying type because Container's conformance witness table is not yet built (ReadyForConformances). The equality-aware constraint solver then fails and control falls through to an equality-blind linear pass that emits the spurious E38029. A function body works because it is checked after every module-scope conformance is already built. This is scope-dependent, and the where T.Element : IMarker conformance variant fails identically — matching the isolation matrix.
• Fix: On the solver's witness-proof failure path, when a constraint carries an unreduced associated-type projection over a concrete aggregate, force that type (and its extensions) to ReadyForConformances and retry once — restoring the reduction the function-body path already gets. Lazy and narrowly-scoped (no effect on already-proving constraints; core-module bootstrap unaffected).
• Tests: New tests/language-feature/generics/generic-assoc-type-eq-constraint-module-scope.slang covers both projection kinds across every module-scope form plus struct/enum extension conformances. Local regression green (generics/diagnostics/interfaces/extensions/enum/autodiff/type, 1410 tests, 0 regressions).
• Next-action: Held as a draft pending automated + human review; not merged (bot policy). Also covers the conformance variant, and likely relates to Valid where clause can fail to validate when using associatedtype generics #6714.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}