Support JET annotations in source code about jet.jl HOT 4 OPEN

Prompted by the discussion in JuliaGraphs/Graphs.jl#249, I'm reconsidering the implementation of this feature.

Before delving into the specifics of annotations, I want to discuss a higher-level approach to implementation. As it stands, the current JET hasn't yet been integrated with JuliaSyntax, hence it seems more convenient to first adopt a macro-based approach, e.g.:

JET.@promise_correct function myfunc(args...)
    [...]
end

Using a macro would necessitate adding a dependency on JET.jl (or a lightweight helper package solely for annotation) on user package side. This would enable us to convey information about user code to JET more simply and reliably. Adding JET.jl to user package dependencies purely for annotation feels excessive, so I propose creating a helper package (let's tentatively call it JETAnnotations.jl) that only defines macros for annotation.

Of course, the comment-based approach is attractive in that it doesn't need any dependencies at all, and I would like to give it a shot in the future. However, I'm a little apprehensive due to concerns about the implementation cost.

Nonetheless, I believe we can maintain compatibility (in most respects) between the macro-based and comment-based features. Therefore, I'm considering starting with a macro-based approach, letting users to experimentally use this feature. Do you have any thoughts or insights on this idea?

/cc @jlapeyre

from jet.jl.

As it stands, the current JET hasn't yet been integrated with JuliaSyntax, hence it seems more convenient to first adopt a macro-based approach...Using a macro would necessitate adding a dependency on JET.jl (or a lightweight helper package solely for annotation) on user package side

Since JuliaSyntax has landed in master, personally I would just make 1.10 a requirement for next-generation JET features. It seems more painful and less readable to putative JET contributors (besides yourself 🙂) to have more meta expressions than an if statement checking a comment. (EDIT: the original version, due to an incomplete edit, gave the opposite impression of what I intended.)

Of course, there is one huge advantage to making packages dependent on a lightweight annotation package: you can declare [compat] bounds. That would give you a mechanism to change the annotations you offer and/or how you name them. That might itself be enough to tip the balance in favor of your macro idea.

Your comments about my specific proposals seem very reasonable. I think this is a case where a mix of "what might a JET-naive developer want?" and "someone who knows what an actual implementation might look like" favors modifying my proposals into a form that gives developers most of what we want while also fitting in naturally with JET's internals.

from jet.jl.

Thank you for your comment. Indeed, the ability to use the [compat] could be a substantial advantage. In the case of a comment-based approach, I anticipate we would need to pay attention to the JET version used for analysis. But it would be more reliable if we can manage the versions of annotations explicitly. Given the challenges associated with the implementation, it seems reasonable to initially adopt a macro-based approach.

As for the features that would be realized after integrating with JuliaSyntax, it seems best to target the v1.10 timeline. This seems like a suitable plan both in terms of code management and my personal bandwidth.

from jet.jl.

• A very simple approach might be to add a comment # JET_PROMISE_CORRECT, and JET will avoid analyzing any calls made at this source line. There's a risk, though, that this is overly broad; as packages undergo further development, this might hide errors different from what prompted adding that annotation in the first place
• Rewording the above as # JET_IGNORE_ERRORS or # JET_NOT_MY_PROBLEM 😆 might be a way to indicate that one wishes to ignore errors from code that one does not plan to fix (e.g., errors from dependencies). Still dangerous, but signals a different intent to readers compared to PROMISE_CORRECT.

Perhaps it would be effective to distinguish between "global" and "local"? That is, imagine using something like # JET_GLOBALLY_IGNORE or # JET_LOCALLY_IGNORE. JET_GLOBALLY_IGNORE would dismiss all errors within the annotated block or method, including those within dependencies, while JET_LOCALLY_IGNORE would ignore errors only within the annotated block or method.

• # JET_WONTCALL push!(::Tuple{}, ::Any) could be used to head off reporting a MethodError that matches the stated signature from any callee of this line. This requires parsing and an eval. Slightly briefer might be to allow dropping the :: but then it's not really Julia syntax 🤔.
• # JET_HASELEMENT might be used to avoid reporting spurious bounds-checking errors as in False positive for indexing Union{Tuple{},Vector{T}} #509. However, I suspect there might be a more systematic fix (my impression from the documentation is that false positives in bounds-checking are not supposed to happen)

What do you think about making JET_[GLOBALLY|LOCALLY]_IGNORE capable of accepting a list of report names as options, and then only those specified reports would be ignored? For example, # JET_WONTCALL could be expressed as # JET_LOCALLY_IGNORE MethodErrorReport, and # JET_HASELEMENT as # JET_GLOBALLY_IGNORE UncaughtExceptionReport. This would indeed require users to have some understanding of JET's report types, but it seems there would be a comparable learning cost even if we prepare individual annotations. Imposing more specific constraints on MethodErrorReport (like method signatures) could be a bit tricky, but it should be possible to create a syntax like MethodErrorReport(t=Tuple{typeof(push!),Tuple{},Any}).

from jet.jl.