Implement panic expression

[ironcev]

Description

This PR introduces the panic expression to the language, as defined in the ABI Errors RFC.

The panic expression can be used without arguments, or accept an argument that implements the std::marker::Error trait. The Error trait is implemented by the compiler for the unit (), string slices, and #[error_type] enums.

Using the panic expression without arguments gives the symetry with the return expression and acts in the same way as having unit as an argument.

panic;
panic ();
panic "This is some error.";
panic Errors::SomeError(42);

Panicking without an argument or with unit as argument is discouraged to use. In the upcoming PR that finalizes the ABI errors feature, we will emit a warning if the panic is used without arguments or with unit as argument.

panic expression is available in all program kinds. In predicates it currently compiles only to revert. Once __dbg intrinsic is implemented, we can consider compiling to it in predicates. In the upcoming PR, the error_codes entry in the ABI JSON will be available for all program kinds.

The dead code analysis for the panic expression is implemented in the straightforward way, following the current approach of connecting reverts to the exit node. This will be revisted in a separate PR, together with the open TODOs in the DCA implementation of Return. Essentially, we want reverting/panicking to connect to program exit and implicit returns to the exit node.

Additionally, the PR:

• extends forc test CLI attributes with --revert-codes that prints revert codes even if tests are successful but revert.
• updates outdated "Logs Inside Tests" chapter in the documentation on unit testing.
• extends the snapshot testing infrastructure to support forc test in snapshot tests.
• fixes Confusing error message when calling __log with invalid number of arguments #7072.

Partially addresses #6765.

Breaking Change

panic is a new reserved keyword. Once the error_type feature becomes integrated, compiling any existing code containing a "panic" as an identifier will result in an "Identifiers cannot be a reserved keyword." error.

In this PR, panic keyword is hidden behind the error_type feature flag. This prevents existing code from breaking, unless opted-in.

Note that, although being behind a feature flag, panic cannot be used in conditional compilation, means in combination with the #[cfg(experimental_error_type = true/false)]. The reason is that cfg evaluation happens after parsing, and we can either parse panic as a keyword or identifier during the parsing, because we cannot distinguish ambiguous cases like panic; or just panic.

This limitation means, that introducing panic to std can be done only once the error_type feature is fully integrated. In practice, this is not a serious limitation, because introducing panic in std would anyhow, due to effort and design decisions, happen after the feature is integrated.

We will provide a migration for this breaking change that will migrate the existing "panic" identifiers to "r#panic".

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[codspeed-hq]

CodSpeed Performance Report

Merging #7073 will not alter performance

_{Comparing ironcev/panic-expression (cd86555) with master (d258921)}

Summary

✅ 22 untouched benchmarks

[sdankel]

The tooling changes look good to me 👍

[kayagokalp]

We seem to have a tiny conflict happy to re-approve once it is fixed as well :)