🔇 Suppress diagnostics caused by already reported errors

[kentookura]

In forester, we have a multiple preorders on source files generated by the different types of links that may be contained within a file.
When an error occurs, the final report produced by asai can be somewhat confusing, as the error that is reported last (meaning it is the most visible) can be the result of an error produced much earlier. For example, If A contains an error, evaluation of B will throws tree A not found.

   transcluded by
A -------------------> B

The final report will look something like this.

Error in A: not valid!
Error in B: A not found!

Now, this example is not too bad but it can quickly grow unwieldy and confusing if the most relevant error is somewhere in a long list of semi-spurious errors. It would be quite simple for me to write some heuristics that order and filter the errors according to some graph-theoretic criteria, but I haven't figured out if the Asai API supports manipulating the reports like this. Any pointers?

Thanks!

[favonia]

@kentookura The API calls the emit effect handler for each diagnostic, so you can intercept them and perform reordering or filtering. I'm happy to go back to the drawing board and add more functionality---we do not have to limit ourselves to the current API. Do you have any suggestion?

[kentookura]

I will try to implement it using your suggestion and report back if I encounter any rough edges or blockers!

[favonia]

@kentookura The better design is to absorb what you plan to implement into the library. 😉

[kentookura]

@favonia I think in order to generalize our use case to library code, Asai needs some notion of dependency or context such that it is possible to omit the diagnostics reported by one "file" (or some other unit of contiguous code) if it depends on some other piece of code that contains errors, or if it emitted inside a specific context. The nice thing about our use case is that it is somewhat clear when such a relationship exists, namely when transclusion fails due to the failure of the inner tree. I wonder what a general API for this might look like...

[kentookura]

@favonia I don't quite understand how to do reordering: Say my goal is to reorder the diagnostics according to their severity. I can keep modifying a reference to a list in the handler, but I don't see how I can control what happens after all diagnostics have accumulated. What I want is to run the computation and accumulate state, and at the end use that state to compute an optimal error report.

[favonia]

@kentookura You need to explicitly access the state with all the accumulated diagnostics. The state should be made available after calling Reporter.run.

[favonia]

@kentookura I'm not sure about reordering diagnostics, but it seems trivial to implement some inefficient suppression. This can also be used to stop the same hint from being displayed, etc. The idea is to have a function Diagnostic.t -> bool that filter future diagnostics.

I'm not sure how to implement this efficiently, though. 🤔

[favonia]

@kentookura I'm repurposing this issue for the common need I saw in mikeshulman/narya#24: suppressing useless diagnostics caused by already reported errors.

[favonia]

@kentookura @mikeshulman If we want a "universal" index type of "causes", what should it be? Or should we avoid such a "universal" type at all costs?

[kentookura]

I am not quite sure what you mean and I think it depends on how such a type would be used in the API. My guess is that the API should not be centered around such a type in such a way as to constrain the manipulation of diagnostics. If the type simplifies the juggling of various diagnostics reported by various sources, then I am all for it.

[favonia]

@kentookura I meant, using your example, how would you write down "A" in some "global database" so that you know it has been reported when checking "B"?