Implement better error types

[seritools]

Right now, it seems that most of the code effectively uses string errors. The Rust bindings use anyhow. While nice for prototyping and applications/CLIs, it prevents the user of the library to get additional context from the returned error. Furthermore, most of the error messages created through anyhow! don't add any extra context and instead just prescribe the formatting existing context already known to the caller.

All four assemble/disassemble function only repackage the inner error message by reformatting it. There, for example, doesn't seem to be a way to get the actual location/span of the error emitted in code, without resorting to actually parsing the error string. I'd imagine there's a plethora of different errors LLVM informs you about, but all this specificity is lost in the conversion to string.

For an assembler/disassembler library getting precise and actionable error output is pretty important IMO.

Personally, I'm partial to snafu for its focus on contextful and composable error types with a philosophy similar to Rust itself, though the most popular crate in that field is thiserror AFAIK.

I'd imagine the assemble error could be represented as something like:

#[non_exhaustive] // this allows extending the error enum further in the future, or turning `Other` errors into different variants in the future
#[derive(Debug, Snafu)]
enum AssembleError {
    #[snafu(display("The instruction at {span:#} is invalid: {reason}"))]
    InvalidInstruction { span: Span, reason: String }
    // ... add other known possible errors here

    // catch-all for unexpected/unhandled errors/exceptions
    #[snafu(display("{message}"))]
    Other {
        message: String
    }
}

[stuxnot]

Thank you for opening the issue. I agree with you, but the current handling of LLVM errors makes this difficult to archieve, since the LLVM Diagnostics are simly formatted via LLVM as strings and then bubbled up.

This will require a refactor on the c++ side, with us keeping the SMDiagnostic ourselves and then returning all extracted information in a custom error instead of a string. Furthermore, we will either need a custom exception -> result conversion function, or have some error type we return from the nyxstone c++ functions which we then convert to results on the rust side.

My current approach would be:

1. Refactor nyxstone to not use extended_error but keep actual SMDiagnostic llvm objects
2. Implement custom exceptions for the possible Diagnostics/Errors in LLVM and Nyxstone
3. Implement custom translation to rust Errors

Since we are currently investigating some issues with the Nyxstone C++ exceptions and apple m1/m2 devices, this plan might change slightly to not actually use exceptions but some other error mechanism.