[DSLX] Internal error constexpr value not found for local type alias

[cdleary]

Describe the bug

fn get_max<N: u32>() -> uN[N] {
    // Note: there is a temporary grammar limitation that prevents us from
    // directly doing `uN[N]::MAX` so we must use a type alias.
    type OutputType = uN[N];
    OutputType::MAX
}

#[test]
fn show_numeric_limits() {
    assert_eq(get_max<u32:4>(), u4:0xf);
    assert_eq(get_max<u32:5>(), u5:0x1f);
}

gives:

Error: [ RUN UNITTEST  ] show_numeric_limits
E0119 13:28:40.597487 1905801 run_routines.cc:110] Internal error: NOT_FOUND: No constexpr value found for node `N` (NameRef) @ /tmp/tmpio5sr9b5.dslx:4:26-4:27
[        FAILED ] show_numeric_limits: internal error: NOT_FOUND: No constexpr value found for node `N` (NameRef) @ /tmp/tmpio5sr9b5.dslx:4:26-4:27
[===============] 1 test(s) ran; 1 failed; 0 skipped.

To Reproduce
Run the DSLX interpreter on the above snippet in a file.

Expected behavior
The type alias should work with the N binding in local scope.

Environment (this can be helpful for troubleshooting):

• OS: Ubuntu
• Versions 24.04.1 LTS

[cdleary]

At a first cut look the trouble seems to come from bytecode emission, not from typechecking.

[cdleary]

Pulling on this thread was a bit rough, still working my way through it, hope I can get a reasonably small when I'm out the other side... TIv2 is in flight so I wanted to avoid too many big changes to TIv1 but I don't think it can be avoided in this case.

The challenge is that when we type infer the generic form the first time around we use parametric symbols, e.g. we infer things like uN[N] with the generic parametric symbol in it.

However, our rules have come to assume they can make note of what's constexpr in the TypeInfo during Deduce rules. So for the first invocation of u32:4, we do note that the parametric environment says that N is constexpr u32:4. For the second invocation, however, we don't put the constexpr in the type info, because we use the cached result from the generic uN[N] form in the type info.

In a nutshell, we used to assume that type inference was monotone, in that we could deduce types the first time in their generic form and then not worry about them later. Now that deduce rules also inject constexpr values into the environment for a particular parametric instantiation, we need to trigger constexpr annotations.

The way I took a shot at this in an initial patch was to create a new derived type info for the generic form, so that we wouldn't end up caching those deduced types in a way the subsequent instantiations would see. That led to some other issues, but seems like generally the right way to go.

The fact the parametric symbol version messes things up instead of helping does sound like a natural opportunity to also remove parametric symbols, but that's yet another step in the rewriting direction, we'll have to see if that's warranted.