Ergonomics: descending into errors

[timholy]

When a call has many errors, it would be nice to have an easier way of iteratively inspecting the context and fixing the cause. One potential option would be to pass each error into Cthulhu.ascend. How do you feel about this idea? If you like it, one thing I'm not yet very familiar with is the API for manipulating the result of report_call. Any brief pointers on where to start reading?

[timholy]

Of course, presumably an even more ergonomic approach would be VScode integration. Now that we have TypedSyntax, do you see other major barriers to implementing this? (In addition to the fact that TypedSyntax is a hack, albeit a useful one, that sometimes makes mistakes.)

[aviatesk]

How do you feel about this idea?

I had never considered that, but it might be worth trying.

If you like it, one thing I'm not yet very familiar with is the API for manipulating the result of report_call. Any brief pointers on where to start reading?

You can get InferenceErrorReport objects from result::JETCallResult returned from report_call with JET.get_reports(result). Each InferenceErrorReport has the vst field, that is a vector of Base.StackFrame-like object, and you can find the errorneous MethodInstance there.

julia> result = @report_call sum("julia");

julia> ascend(report.vst[end].linfo)
Choose a call for analysis (q to quit):
 >   add_sum(::Char, ::Char)
       (::Base.BottomRF{typeof(Base.add_sum)})(::Char, ::Char)
         _foldl_impl(::Base.BottomRF{typeof(Base.add_sum)}, ::Base._InitialValue, ::String)
           foldl_impl(::Base.BottomRF{typeof(Base.add_sum)}, ::Base._InitialValue, ::String)
             mapfoldl_impl(::typeof(identity), ::typeof(Base.add_sum), ::Base._InitialValue, ::String)
               #mapfoldl#294(::Base._InitialValue, ::typeof(mapfoldl), ::typeof(identity), ::typeof(Base.add_sum), ::String)
                 mapfoldl(::typeof(identity), ::typeof(Base.add_sum), ::String)
                   #mapreduce#298(::Base.Pairs{Symbol, Union{}, Tuple{}, @NamedTuple{}}, ::typeof(mapreduce), ::typeof(identity), ::typeof(Base.add_sum), ::String)
                     mapreduce(::typeof(identity), ::typeof(Base.add_sum), ::String)
v                      #sum#301(::Base.Pairs{Symbol, Union{}, Tuple{}, @NamedTuple{}}, ::typeof(sum), ::typeof(identity), ::String)

[aviatesk]

Of course, presumably an even more ergonomic approach would be VScode integration. Now that we have TypedSyntax, do you see other major barriers to implementing this? (In addition to the fact that TypedSyntax is a hack, albeit a useful one, that sometimes makes mistakes.)

Yes, I think JET should use TypedSyntax to display reported problems, since the current situation is also hacky and not very accurate (it tries to "infer" the original textual representation from the lowered form). I have three concerns about integrating TypedSyntax into JET:

• JET actually has two different analyzers: the one for report_call inspects the unoptimized type-inferred lowered form, and the other for report_opt does so on the optimized type-inferred lowered form. Since, as far as I understand, TypedSyntax can work with unoptimized type-inferred lowered forms, I think we can integrate it with report_call only. Although this would be a significant improvement itself, to make it work with the optimized form, we would need to tweak base Julia so that the compiler maintains the original textual representation throughout the compilation pipeline.
• Performance issues: I am mostly concerned about the performance cost. Under the current design, JET constructs an internal data structure during abstract interpretation that contains certain information (like the error location, the call signature, etc.) which is necessary for displaying JET's stacktrace-like view to users. The integration of TypedSyntax replaces this information with the new one that is required for TypedSyntax, so as long as the integration tries to show the stacktrace-like view to users, it needs to perform some computations during abstract interpretation. I am willing to accept some computational costs as the TypedSyntax-based view would be much nicer (and I don't think the current implementation is very optimized anyway), but I would like to make JET as fast as possible. If necessary, I am even fine with creating a new mode of JET where we forgo showing the stacktrace-like view and just show the error location to users. In this case, the performance cost would be negligible.

Additionally, we may need to make some changes to TypedSyntax: as far as I remember, TypedSyntax works on the unoptimized form where inference has been completed. However, if we maintain the current design of JET, we need to make it work on the unoptimized lowered form where inference is still in progress but when the type information about the statement in question is available.