Emphasize mismatching part of complex type mismatches

[abs0luty]

• Closes Emphasize mismatching part of complex type mismatches #4578

[abs0luty]

@lpil what's your opinion on when to display errors this way?

[giacomocavalieri]

I would also like to think how these will appear in different settings. As nice as this looks when running gleam build I think it could get confusing real fast when the error pops up in an IDE like Zed or VSCode where wrapping can happen:

• VSCode:
• Zed:

[lpil]

That looks like a bug in Zed to me @giacomocavalieri. We tell it to render it as markdown.

[giacomocavalieri]

Yeah, the wrapping can still make it hard to read though

[abs0luty]

@giacomocavalieri Good point about wrapping. Thanks! I think we can solve it in many different ways:

We can break the mismatch into bullet points under the main message. Something like "Mismatch at argument 2: expected Float, found String" without trying to align under the original text, or something like this:

Box(#(#(Int, a), b, List(c)))

Expected a to be Float, found String
Expected b to be Float, found Int
Expected c to be Float, found Int

Or even separate error messages:

Box(#(#(Int, ...), Int, List(Int)))
  
Expected type: Float
Found type: String

Box(#(#(Int, String), ..., List(Int)))
  
Expected type: Float
Found type: Int

Box(#(#(Int, String), Int, List(...)))
  
Expected type: Float
Found type: Int

We can also control the block width manually (e.g., add zero-width spaces or break into smaller lines ourselves), although there's always a limit to this:

Box(
  #(
    #(Int, String),
           ^^^^^^ expected Float
    Int,
    ^^^ expected Float
    List(Int)
         ^^^ expected Float
  )
)

What do you think?