Instead of reusing instructions from the generic entity in the eval block, rebuild constants in the same way we rebuild types. The previous attempt to not rebuild these constants assumed that every constant used in a generic would be built in that generic, and not referenced directly or referenced from some enclosing scope, which isn't true in practice and is a fragile assumption in any case.
We could add back some reuse of instructions from the generic -- if we happen to see the right instruction to build a constant, we could opportunistically reuse it -- but given the complexity added by doing so, I'm not pursuing that here.
Now that the eval block for a generic consists of instructions uniquely owned by that generic, rather than often being shared with another entity, include the generic in the formatted SemIR output. I'm using the same scope name for the generic object itself as for the parameterized class / function / interface, because there are very frequently references between them and this keeps the IR simpler and more readable, and avoids needing to invent a second name for the scope.
Instead of reusing instructions from the generic entity in the eval block, rebuild constants in the same way we rebuild types. The previous attempt to not rebuild these constants assumed that every constant used in a generic would be built in that generic, and not referenced directly or referenced from some enclosing scope, which isn't true in practice and is a fragile assumption in any case.
We could add back some reuse of instructions from the generic -- if we happen to see the right instruction to build a constant, we could opportunistically reuse it -- but given the complexity added by doing so, I'm not pursuing that here.
Now that the eval block for a generic consists of instructions uniquely owned by that generic, rather than often being shared with another entity, include the generic in the formatted SemIR output. I'm using the same scope name for the generic object itself as for the parameterized class / function / interface, because there are very frequently references between them and this keeps the IR simpler and more readable, and avoids needing to invent a second name for the scope.