Improve error message for illegal enum variants

[jjcnn]

Description

Fixes #4942.

Please do review this carefully. I've added a test triggers the new error message, but I might very well have forgotten to add something somewhere.

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).
• 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.

[ironcev]

A few slight changes in the message text, to make it compatible with the diagnostic guidelines.

Since this is a new diagnostic, we also need to add the Diagnostic to the error, this is missing currently.

We don't have Diagnostic so far in the parsing phase, so let's leave that part out for now.

[ironcev]

@jjcnn @IGI-111 This minimal change is already a big improvement compared to what we have now. It clearly indicates the issue and the expected variant formats. So I'm definitely for merging it.

However, after giving it additional thought, I'm thinking again about a bit more ambitious solution, which was my original thought on the GitHub issue. Recognizing Rust specific patterns and showing concrete solution for the issue, how the same code should look in Sway.

That would mean adding Diagnostic to the CompileError::Parse which we don't have now, and extended the parser to actually parses two typical Rust examples. Both changes are rather simple and will allow us to have messages like these:

error: Enum variant declaration is not valid

enum Enum1 {
  Ok,    // Illegal
  ^^ `Ok` is not a valid enum variant declaration.
  -- help: Did you mean `Ok: ()`?

help: In Sway, enum variants are in the form `Variant: ()`, `Variant: <type>`, or `Variant: (<type1>, ..., <typeN>)`.
help: E.g., `Foo: (), `Bar: u64`, or `Bar: (bool, u32)`.

error: Enum variant declaration is not valid

enum Enum2 {
  F(u32),        // Illegal
  ^^^^^^ `F(u32)` is not a valid enum variant declaration.
  ------ help: Did you mean `F: (u32)`?

help: In Sway, enum variants are in the form `Variant: ()`, `Variant: <type>`, or `Variant: (<type1>, ..., <typeN>)`.
help: E.g., `Foo: (), `Bar: u64`, or `Bar: (bool, u32)`.

error: Enum variant declaration is not valid

enum Enum3 {
  A(MyType, bool, u8),
  ^^^^^^^^^^^^^^^^^^^ `A(MyType, bool, u8)` is not a valid enum variant declaration.
  ------------------- help: Did you mean `A: (MyType, bool, u8)`?

help: In Sway, enum variants are in the form `Variant: ()`, `Variant: <type>`, or `Variant: (<type1>, ..., <typeN>)`.
help: E.g., `Foo: (), `Bar: u64`, or `Bar: (bool, u32)`.

We do not have to parse the Rust struct-like variant. That would be a bit too much work, and it's also not a kind of a mistake Sway programmers do. In that and all other cases we can go for the common help message at the bottom of the message without the particular suggestion.

error: Enum variant declaration is not valid

enum Enum4 {
  A { x: i32, y: i32 },
  ^^^^^^^^^^^^^^^^^^^ `A { x: i32, y: i32 }` is not a valid enum variant declaration.

help: In Sway, enum variants are in the form `Variant: ()`, `Variant: <type>`, or `Variant: (<type1>, ..., <typeN>)`.
help: E.g., `Foo: (), `Bar: u64`, or `Bar: (bool, u32)`.

But for the other three cases, having a precise solution in the error message has a benefit.

Also, adding the first Diagnostic for CompileError::Parse will pay off in the mid and long term.

Let me know what you think.

[IGI-111]

I think it is a good idea to get additional information to help the most common issues, but unless Rust confusions are really that common it's probably over-engineering.

Helpful errors are important and I really like your examples, but improving errors for cases that aren't as niche is likely a better use of our ressources at this time. Maybe you should put this idea in a separate issue and we can bikeshed it and/or pick it up when we'll have a serious go at polishing our errors.

In any case, we should get this PR's improvement first.

[ironcev]

Maybe you should put this idea in a separate issue and we can bikeshed it and/or pick it up when we'll have a serious go at polishing our errors.

Done: #5403

[jjcnn]

Review comments addressed.