refactor a bit

[chanced]

Hey @asmello, I made some changes for you to review. High level:

• renames SRC generic of Report to D and bound it to Diagnostic
• drops SUB in generic, uses D::Subject instead
• removes lifetime from Report
• removes seal for Diagnostic
• Adds associated type Related and method related to Diagnostic for multi-errors

Regarding lifetimes, I really think we should only deal with owned subjects. It simplifies the code considerably, reduces boilerplate, avoids borrowck issues, and doesn't cost much; a single allocation at worst on an error path for reporting seems more than fair. Given that this behavior is opt-in, I say we keep it simple.

I really don't know about the multi-error list. We can include it and I made some changes to support it, but I don't know how valuable it'll be. However, it is possible with this structure. To support it, we will need a struct ParseErrors(Box<[ParseError]> that would have a Related = ParseError and I'll need to move over the logic from the other branch.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 76.21622% with 44 lines in your changes missing coverage. Please review.

Project coverage is 95.9%. Comparing base (1404c61) to head (8a07c9f).

Files with missing lines	Patch %	Lines
src/resolve.rs	53.5%	13 Missing ⚠️
src/pointer.rs	87.6%	10 Missing ⚠️
src/assign.rs	57.1%	9 Missing ⚠️
src/diagnostic.rs	76.9%	6 Missing ⚠️
src/token.rs	80.7%	5 Missing ⚠️
src/index.rs	66.6%	1 Missing ⚠️

Additional details and impacted files

Files with missing lines	Coverage Δ
src/index.rs	92.2% <66.6%> (-4.8%)	⬇️
src/token.rs	97.6% <80.7%> (-2.4%)	⬇️
src/diagnostic.rs	77.1% <76.9%> (-0.7%)	⬇️
src/assign.rs	97.6% <57.1%> (-1.5%)	⬇️
src/pointer.rs	95.7% <87.6%> (-0.9%)	⬇️
src/resolve.rs	93.6% <53.5%> (+4.5%)	⬆️

[chanced]

Sorry I went awol on this. I'll be heading home tomorrow and this will be my first priority.

[chanced]

@asmello So the time I had allocated after my trip to work on this was unfortunately spent sick. I have had time to tinker with it here and there but I'm struggling to nail down a design with regard to mutli-errors.

The biggest hurdle is that miette::Diagnostic::related expects a return of an optional Iterator<Item = &'a dyn miette::Diagnostic>.

I considered OnceLock + a borrowed flavor of Report but that doesn't work as they cannot be generated on the fly and returned. The only way to properly display them, so far as I can reason, is cloning the subject/sourcecode for each error - albeit lazily (via OnceLock). That way the related errors can satisfy miette::Diagnostic and display the pointer (related errors are displayed as an independent error, disconnected from the original).

I'm at the point where I'm pretty certain that related errors just aren't worth it. It spikes the complexity considerably with little upside (if a pointer is malformed, its malformed and as pointers are likely something being generated by logic, i don't know how many users would really benefit from having a detailed demonstration.

I think everything else is solid and I'll finish it out, hopefully sometime this weekend. We can decide whether to proceed without them from there.

[chanced]

There's an issue with reporting being displayed twice and the root error seems to be acting as a passthrough:

[chanced]

I "fixed" the issue of repeated sourcing by returning self.source.source() from Error::source on Report. I experimented with a whole bunch of different options but I cant think of any other way to go about it. I thought I had something with miette::Diagnostic::diagnostic_source but that return -> Option<&dyn Diagnostic> really put a kink in creating lifetime toting enums for specifically for that purpose.

I modified the error messages such that each error does not delve into the source, displaying only information at that depth:

[chanced]

We could provide richer error messages for Report as we have the source. However, this would mean that the error messages would vary depending on whether you Pointer::parse or PointerBuf::parse.