Error refactoring and thiserror 2.0

[PhilippGackstatter]

Use thiserror 2.0 and refactor errors to be mostly in line with how our other errors are structured, e.g. see 0xPolygonMiden/miden-base#972.

So this changes errors to use lowercase messages without trailing punctuation and prefer source style over wrapping source errors.

Other notable changes include:

• SourceManagerError::Custom variant which, I think, makes sense to include as SourceManager is a trait implementable by other crates which cannot add variants to SourceManagerError. Let me know if this is not what we want.
• Similarly, EventError(String) was changed to EventError(Box<dyn Error>).
• Not using #[source] for errors that turn into Report, because Report does not implement core::error::Error and so source errors would be effectively swallowed that way.

There is a problem with building the assembly crate for wasm/no-std with this change. If I understand everything correctly, then this is because of the following. miden_miette uses miden_thiserror which exposes StdError. If we use neither a nightly compiler nor the std flag then StdError is not a reexport of the core::error::Error type but rather a copy of the Error trait, which means it is a separate type. miden_miette however with its Diagnostic trait expects StdError and that trait is no longer implemented by some errors, like SyntaxError. This previously worked because we used miden_thiserror to derive errors and so in that configuration, the derived error was StdError and that always matched what miden_miette was expecting.

It seems to me the proper fix would be to modify miden_miette to use thiserror 2.0. I've tested this change locally and both std and no-std works. This would make miden_thiserror obsolete, and we could consider yanking that crate.
My question is whether we want to go ahead with this change in miden_miette or not. Pinging @bitwalker, as I think you've made the no-std changes to miden-thiserror and miden-miette.

Or should we go one step further and ask if the miette author would be open to have the no_std changes upstreamed?

closes #1261

[bobbinth]

It seems to me the proper fix would be to modify miden_miette to use thiserror 2.0. I've tested this change locally and both std and no-std works. This would make miden_thiserror obsolete, and we could consider yanking that crate.
My question is whether we want to go ahead with this change in miden_miette or not. Pinging @bitwalker, as I think you've made the no-std changes to miden-thiserror and miden-miette.

I would modify miden_miette for now and then get rid of miden-thiserror. In parallel, we can also see if miette could switch to the latest thiserror - but I think that would be a separate task.

[PhilippGackstatter]

I would modify miden_miette for now and then get rid of miden-thiserror. In parallel, we can also see if miette could switch to the latest thiserror - but I think that would be a separate task.

Sounds good.
I tried to git push a branch to our miette fork but got this, maybe you can add me as a collaborator?

ERROR: Permission to 0xPolygonMiden/miette.git denied to PhilippGackstatter.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I would do only the minimal necessary changes for now, because updating our miette fork from 7.1.0 to the latest miette at 7.4.0 comes with a bunch of conflicts. And if we can get miette to support no_std and use thiserror 2.0 then that will be obsolete.

[bobbinth]

I tried to git push a branch to our miette fork but got this, maybe you can add me as a collaborator?

You should be able to write to it now.

I would do only the minimal necessary changes for now, because updating our miette fork from 7.1.0 to the latest miette at 7.4.0 comes with a bunch of conflicts. And if we can get miette to support no_std and use thiserror 2.0 then that will be obsolete.

Yes, let's do the minimal changes for now.