Using an invalid type alias reports cascading errors

[RevolvingMadness]

The following code:

pub type UnknownTypeAlias = UnknownType

pub type UsageOfUnknownTypeAlias = UnknownTypeAlias

Produces the error:

error: Unknown type
  ┌─ /src/main.gleam:1:29
  │
1 │ pub type UnknownTypeAlias = UnknownType
  │                             ^^^^^^^^^^^

The type `UnknownType` is not defined or imported in this module.

error: Unknown type
  ┌─ /src/main.gleam:3:36
  │
3 │ pub type UsageOfUnknownTypeAlias = UnknownTypeAlias
  │                                    ^^^^^^^^^^^^^^^^

The type `UnknownTypeAlias` is not defined or imported in this module.

I would expect the first error to be reported as the type UnknownType really doesn't exist. However with the second error, I wouldn't expect it to be reported to the user until they get the previous error fixed to prevent cascading errors.

Interestingly enough:

pub type UnknownTypeAlias = UnknownType

pub type UnknownTypeAlias {}

reports

error: Duplicate type definition
  ┌─ /src/main.gleam:1:1
  │
1 │ pub type UnknownTypeAlias = UnknownType
  │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Redefined here
  ·
5 │ pub type UnknownTypeAlias {}
  │ ------------------------- First defined here

The type `UnknownTypeAlias` has been defined multiple times.
Names in a Gleam module must be unique so one will need to be renamed.

which acknowledges that the alias UnknownTypeAlias has already been defined which contradicts

error: Unknown type
  ┌─ /src/main.gleam:3:36
  │
3 │ pub type UsageOfUnknownTypeAlias = UnknownTypeAlias
  │                                    ^^^^^^^^^^^^^^^^

The type `UnknownTypeAlias` is not defined or imported in this module.

Tested on the Gleam Playground with Gleam version 1.17.0 and on Arch Linux with Gleam version 1.18.0

[jamesdolan16]

I'd like to pick this one up please

[RevolvingMadness]

Is there any interest in adding an Error variant to compiler_core::Type which currently only holds valid data types so that, that would be used when an invalid type is present? This would ideally prevent cascading errors everywhere just by adding this although you would need to handle the Error variant everywhere which is a pain but it should get rid of all cascading errors related to invalid data types.

[jamesdolan16]

Is there any interest in adding an Error variant to compiler_core::Type which currently only holds valid data types so that, that would be used when an invalid type is present? This would ideally prevent cascading errors everywhere just by adding this although you would need to handle the Error variant everywhere which is a pain but it should get rid of all cascading errors related to invalid data types.

@RevolvingMadness I did consider this but I felt the changes would be too intrusive for the reason you state, you'd have to handle the new variant everywhere and I'm not experienced enough in the Gleam codebase to know if that's worth the tradeoff.

[RevolvingMadness]

That question wasn't meant to be directed at you as your changes look fine in terms of how things are currently structured, it was a question more for the developers of the compiler. I should've asked that question in my initial post. 😅

[GearsDatapacks]

Normally we use an unbound type as a placeholder for errors, as unbound types unify with everything. I'm not totally sure what the issue is in this particular case though.

[lpil]

What would this new variant do and how would it prevent cascading errors?

[RevolvingMadness]

Given the rust code

let x = () + ();

the type of x would be Error and a new diagnostic would be emitted.

When x is used someplace else, say

x + 5

it would check is Error + Int valid? Because there is at least one error type in either data type, the resulting type of the addition is Error and no diagnostic would be emitted until the type of x is valid.

Though maybe using unbound types in this case would be a better solution.

[GearsDatapacks]

The equivalent Gleam code to that only produces one warning currently: https://playground.gleam.run/#N4IgbgpgTgzglgewHYgFwEYA0IDGyAuES+aIADgK4BGABAGZI0C2AhnEgBQCUNwAOoxoAbCPhoAPGgF4afECzk0A1LJBU5AmhOU0ArAIC+AkAaA=