Implement marker traits

[ironcev]

Description

This PR introduces the concept of marker traits to the language. It is the first step towards implementing the ABI errors RFC.

Marker traits are traits automatically generated by the compiler. They represent certain properties of types and cannot be explicitly implemented by developers.

The PR implements a common infrastructure for generating and type-checking marker traits as well as two concrete marker traits:

• Error: represents a type whose instances can be used as arguments for the panic expression. (The panic expression is yet to be implemented.) In this PR, it is implemented only for string slices. In the upcoming PR it will be implemented for enums annotated with the #[error_type] attribute.
• Enum: represents an enum type. It is inspired by the Rust's experimental Tuple marker trait and used in this PR as a sample marker trait, to develop and test the marker trait autogeneration.

Marker traits allow developers expression constraints related to certain properties of Sway types. As an illustration, if developers want to express a constraint such is "the error type must be an error enum", they can do it by combining the two marker traits:

fn panic_with_error<E>(err: E) where E: Error + Enum {
    panic err;
}

Note that the generic name Enum is sometimes used in our tests to represent a dummy enum. In tests, it is almost always defined locally, and sometimes explicitly imported, so it will never clash with the Enum marker trait. A single test in which the clash occurred was easily adapted by explicitly importing the dummy Enum.

The PR is the first step in implementing #6765.

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 #6871 will not alter performance

_{Comparing ironcev/marker-traits (c02f83e) with master (55358da)}

Summary

✅ 22 untouched benchmarks

[IGI-111]

I'm not sure we want to restrict ABI errors to be necessarily Enums, what's the rationale behind having to check this particular constraints in a trait impl instead of being more generic?

[ironcev]

I'm not sure we want to restrict ABI errors to be necessarily Enums, what's the rationale behind having to check this particular constraints in a trait impl instead of being more generic?

@IGI-111 The ABI errors are not necessarily Enums, on the contrary. Currently, in this PR, they are implemented only for string slices. Perhaps is the example given in the description misleading. The idea of the example was to demonstrate the usage of marker traits in general - writing generic code that has constraints on different type properties.

Error will be implemented for #[error_type] enums in the upcoming PR. If we decide later to have other types supporting Error, we can always extend the support. E.g., supporting u64 and still alow developers to use error codes.

But the question leads me to the questionable purpose of the Enum trait, so a bit of a background for having it in this PR.

Since the full-blown Error on enums is coming in the next PR, to build and test the general infrastructure for marker traits, I needed a suitable, simple marker trait with auto-implementations on elgible types. Enum marker was a simple choice inspired by the Rust's experimental Tuple marker trait.

Once started playing with it, I realized that it actually fits nicely with the Error marker in case developers intentionally want to restrict errors to be enums. E.g., using string slices in panic increases code size to embed slices. A design agreement to stick to error enums, where the error strings are not embedded in code, could be then enforced on the API that panics with given error in a way shown in the description.

This might be a far stretched use case for a real world application, but as with all new language features, it is hard to anticipate how far devs will take it. I am fine with removing Enum marker trait in the upcoming PR if we agree so. But by then, in this PR, to implement and tests the overall approach to marker traits, we need a simple sample trait to start with.

I'll adapt the PR description to better convey the choices done in this PR and to avoid misleading example.

[jjcnn]

All looks good except CallPath::to_string_with_args, which I think needs to be tweaked.