Implement support for typed catch clauses

[jianlingzhong]

This change updates the try special form to support multiple, typed catch clauses, enabling more granular exception handling and C++ interop.

Key changes:

Syntax: catch clauses now require an explicit type argument (e.g., (catch cpp/jank.runtime.object_ref e ...)).
Parser: Updated parse_try to handle multiple catch clauses with their corresponding types.
Codegen: Extended LLVM IR generation to support multiple catch blocks.
Tests: Updated existing tests to use the new explicit catch syntax and added new tests for multiple catches, nested try-catch-finally blocks, etc..

[jeaye]

Thanks for all the work, Jianling. This is not ready for any more review, I think.

To start with, we have a LOT of new code here and not much documentation to follow it. Also, a lot of the new code doesn't match jank's style, for things you know we do. CI is also failing, since the tests don't pass.

The testing changes include a large amount of over-testing, which I suspect comes from an LLM rather than a conceived testing plan. I tried to identify the redundancies, but honestly there's so much that I know I missed some.

I know this feature is complex. That is all the more reason why we need to carefully craft it, though.

[jeaye]

There's no need for an option here, now that we're using a vector. Before, we could have 0 or 1 catch body, so we used an option. Now we can have 0 or N, which the vector affords us.

[jeaye]

This can be removed by not using an option for catch bodies anyway.

[jianlingzhong]

we don't have a "to_runtime_data" for native_vector, so we still need it.

[jeaye]

Ok, in that case we need to fix the code. The (void) you added is to silence an error telling you that you're not using the data structure correctly. This is a persistent vector. You cannot change it. So push_back returns a new vector, which you're ignoring. In this code, ret starts empty and remains empty through the loop.

If you create a transient vector, you can mutate that before turning it into a persistent vector.

[jeaye]

1. This is a very heavy-weight option. Resolving literal types like this requires JIT compiling C++ code, which is the slowest thing jank can do. What about just using Cpp::GetType("char")?
2. Please use direct initialization.

[jianlingzhong]

we cannot. using Cpp::GetType("char") would fail the following test:

(cpp/raw "void throw_char_z() { throw 'z'; }")

(assert
 (= \z
    (try
      (cpp/throw_char_z)
      (catch cpp/int i
        (println "Wrong: caught int")
        \0)
      (catch cpp/char c c))))

and the IR generated is using a "signed char"

  invoke void @clojure_core_G__24202(ptr null, i32 0, ptr null, ptr null)
          to label %invoke.cxx.normal unwind label %lpad

lpad:                                             ; preds = %entry
  %1 = landingpad { ptr, i32 }
          catch ptr @_ZTIi
          catch ptr @_ZTIa  # <-- signed char

if we use resolve_literal_type("char"), then the IR we got is:

  invoke void @clojure_core_G__24203(ptr null, i32 0, ptr null, ptr null)
          to label %invoke.cxx.normal unwind label %lpad

lpad:                                             ; preds = %entry
  %1 = landingpad { ptr, i32 }
          catch ptr @_ZTIi
          catch ptr @_ZTIc # <-- char

[jeaye]

This should not be needed, since it's declared in the header file, which we include.

[jeaye]

This isn't correct English anymore. Error messages must be very clear, with correct grammar. Also, a body is not required for a catch clause. Maybe something like:

Each 'catch' form requires the type of exception to catch and a symbol for the name of the exception value.

[jeaye]

This pointer can be const.

[jeaye]

Please always use direct initialization.

[jeaye]

Starting here, we have nearly 300 lines of code which are not documented. There are a few comments, but they all say WHAT, not WHY. We need to do more here.

[jeaye]

Why only macOS?

[jeaye]

Pleas use native_vector unless you're interacting with an API which requires std::vector.