[Feature Request]: System for writing hints to JET into package code

[MasonProtter]

I think it'd be useful if at least for the purposes of report_file, there was a way to write hints to JET as comments in the source code.

I'm thinking of something like

module TestPackage

# JET-hint: x::Union{Int, Float64, Matrix{Complex{Float64}}}
function foo(x)
    #JET-hint assume_safe: √
    √x + one(x)
end

end # module TestPackage

The idea here would be that running report_package(TestPackage) would see these comments, and instead of trying to analyze f(::Any) or just not analyzing f, it would analyze f(::Union{Int, Float64, Matrix{Complex{Float64}}}), basically as a use-supplied heuristic for what sorts of types they expect this function to take.

While analyzing that definition, it could make use of the #JET-hint assume_safe: √ to not analyze √, and instead just use the inferred return type of √x to continue analyzing.

[jariji]

#JET-hint assume_safe: √

I assume this is intended to avoid having to see JET errors for sqrt throwing exceptions for negative argument.

I don't like the idea of simply declaring sqrt "safe" at a call site: On what grounds could we know that? From our perspective as the caller of sqrt, we only know about x -- we don't necessarily know all the prerequisites of sqrt.

I would prefer that the definition of sqrt have a specified contract including predicates labeled "preconditions". Then we the caller can assert various conditions on x, and JET can line up our assertions about x with sqrt's preconditions and determine for itself whether sqrt(x) is safe.

[MasonProtter]

I assume this is intended to avoid having to see JET errors for sqrt throwing exceptions for negative argument.

I don't like the idea of simply declaring sqrt "safe" at a call site: On what grounds could we know that? From our perspective as the caller of sqrt, we only know about x -- we dont' necessarily know all the prerequisites of sqrt.

This doesn't affect the execution or running of the program at all (it's a comment), so there's nothing unsafe about it. All I'm saying is that I want a way to communicate to JET "please don't waste time, or visual space analyzing and reporting from inside sqrt, just ignore it and move on"

I would prefer that the definition of sqrt have a specified contract including predicates labeled "preconditions". Then we the caller can assert various conditions on x, and JET can line up our assertions about x with sqrt's preconditions and determine for itself whether sqrt(x) is safe.

I see that as a pretty separate request, and also one that I'd argue is out of scope for JET.

[jariji]

I'm saying is that I want a way to communicate to JET "please don't waste time, or visual space analyzing and reporting from inside sqrt, just ignore it and move on"

I think this is a decision best made by the callers of report_package, who might have disparate needs, not the caller of sqrt. The function writer doesn't know what the end user's requirements are.

For example, different users might have:

• Situation 1: foo(x) MUST NOT fail but it won't because we validated that x >= 0 before calling foo(x).
• Situation 2: sqrt(x) might fail and I have no reason to think it won't but I don't care, that's not the kind of problem I'm worried about, if it fails it fails. Just don't flood my diagnostic report, so I can focus on other issues.

So consider a tag/label system. Function writer says

function foo(x)
    # jet-label: √x validated
    √x + one(x)
end

and the Situation 1 end user says:

report_package(P, ignore_labels=[:validated])

---

The signature hint

# JET-hint: x::Union{Int, Float64, Matrix{Complex{Float64}}}
function foo(x)

seems like a discussion to be had in a separate issue from the "ignore this" API.

[MasonProtter]

I think this is a decision best made by the callers of report_package, who might have disparate needs, not the caller of sqrt. The function writer doesn't know what the end user's requirements are.

So we agree? That hint is only there for the purposes of report_package. It's a code comment in the source code of foo. It would only ever be seen by JET if you called report_package(TestPackage) or report_file("TestPackage/src/TestPackage.jl").

If someone else had their own package that calls foo, and they ran JET on it, JET wouldn't be aware of those comments at all, because those comments don't exist in the code representation JET sees normally.