You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you get a type error in a helper routine, e.g. that uses parametrics, a type error will be identified in the leaf, but we don't currently display the calling context. We do maintain this information during typechecking (in DeduceCtx::fn_stack), so it would be good to capture/display it when producing an error message display.
Current best alternative workaround (limit 100 words)
It's tricky to figure out where things are coming from as it seems like we don't have trace_fmt! emit output at constexpr evaluation time right now.
Your view of the "best case XLS enhancement" (limit 100 words)
We'd display the function stack that led to the type error (in the leaf function) as part of the error display.
The text was updated successfully, but these errors were encountered:
What's hard to do? (limit 100 words)
If you get a type error in a helper routine, e.g. that uses parametrics, a type error will be identified in the leaf, but we don't currently display the calling context. We do maintain this information during typechecking (in DeduceCtx::fn_stack), so it would be good to capture/display it when producing an error message display.
Current best alternative workaround (limit 100 words)
It's tricky to figure out where things are coming from as it seems like we don't have
trace_fmt!
emit output at constexpr evaluation time right now.Your view of the "best case XLS enhancement" (limit 100 words)
We'd display the function stack that led to the type error (in the leaf function) as part of the error display.
The text was updated successfully, but these errors were encountered: