Error type

[IGI-111]

This is a tracking issue for the RFC ABI Errors.
The experimental feature flag for the issue is error_type.

Description

For detailed description see the RFC ABI Errors.

Breaking Changes

Rename existing "panic" identifiers

ABI Errors introduce a new keyword to the language: panic. This means that compiling any existing code containing a "panic" as an identifier will result in an "Identifiers cannot be a reserved keyword." error.

E.g.:

fn panic() { }

or

let panic = 42;

will produce the "Identifiers cannot be a reserved keyword." error.

The proposed solution to this error is to rename any existing "panic" identifiers to their raw identifier form, "r#panic":

E.g., the above examples will become:

fn r#panic() { }

let r#panic = 42;

Check name clashes with existing types called Error or Enum

The error_type feature introduces two new traits in the core prelude: core::marker::Error and core::marker::Enum.

If the existing code already has types with those names, and only if those types are imported via glob (*) import the "Multiple bindings exist for symbol in the scope" error will be emitted.

E.g., suppose that we have a type my::impls::Error, and import it in scope by use my::impls::*. After migrating to error types, the following error will appear:

error: Multiple bindings exist for symbol in the scope
   --> /src/main.sw:118:51
  |
1 | my_fn::<Error>(14);
  |         ^^^^^ The following paths are all valid bindings for symbol "Error": "core::marker::Error" and "my::impls::Error".
  |
  = help: Consider using a fully qualified name, e.g., `my::impls::Error`.

The solution is, as proposed in the help message, to either fully qualify the Error symbol, or to import it by specifying its full path: use my::impls::Error.

Steps

• Introduce marker traits and implement Error marker trait.
• Implement #[error_type] and #[error] attributes.
• Implement panic expression.
• Generate ABI with error information.
• Implement migration steps.