gleam-lang/gleam

Summary Gleam 1.19.1 emits malformed abstract code (debug_info) for a pub opaque type whose constructor references another local, user-defined type. The reference is encoded as {type, Line, Name, []} (the form reserved for built-in types) instead of {user_type, Line, Name, []}. Dialyzer then crashes with a function_clause in erl_types:from_form/5, because there is no clause for a "built-in" type named after a user type. This is a regression: Gleam 1.18.1 did not exhibit it. Environment Gleam: 1.19.1 Erlang/OTP: 29 (reproduced on both erts 17.0.5 and 17.1) OS: Windows 10 (also expected on Linux/macOS - it is a codegen issue) Minimal reproduction gleam new repro --template erlang, then src/repro.gleam: pub type Kind { Const(Int, Int) Linear(Int, Int) } pub opaque type Range { Range(origin: Int, kind: Kind) } pub fn make() -> Range { Range(0, Const(1, 2)) } gleam build, then inspect the beam's abstract code: erl -noshell -eval ' {ok,{_,[{abstract_code,{_,Fs}}]}} = beam_l

The official documentation [1] states that the constructors for the opaque type are private and can only be used by the module that defines the type, however, I found that they work just fine in foreign modules when used with const. For instance, Timestamp is an opaque type defined in gleam_time package, but works fine in the following example: import gleam/time/timestamp const zero = timestamp.Timestamp(seconds: 0, nanoseconds: 0) pub fn main() { echo zero Nil } Since I could not find more on the topic in any other publicly accessible forum, I am assuming its unintended behavior, but please correct me if I got this wrong. I noticed it first in the version 1.19.0 of the compiler, and haven't checked it in any of the previous versions. 1: https://tour.gleam.run/everything/#advanced-features-opaque-types

My use case is replacing a catch-all pattern _ -> Error(Nil) with a single branch. If I use add missing patterns, I get this: AbilityUsed(_, ability_index:, by:) -> todo CardPlaced(_, into:) -> todo CardsDiscarded(_) -> todo CardsToasted(_) -> todo CardsDrawn(_, _) -> todo PowerGained(_, _) -> todo PowerGenerated(_, _) -> todo PowerGenerationSkipped(_) -> todo PowerSpent(_, _) -> todo There is a merge case branches LS action but it requires to manually remove the matched fields, like so: AbilityUsed(..) -> todo CardPlaced(..) -> todo CardsDiscarded(_) -> todo CardsToasted(_) -> todo CardsDrawn(_, _) -> todo PowerGained(_, _) -> todo PowerGenerated(_, _) -> todo PowerGenerationSkipped(_) -> todo PowerSpent(_, _) -> todo My proposal would be that add missing patterns uses .. for all the variants payloads. If you need to use labels, you can use th

Since Gleam utilizes one of a number of underlying binaries on a users system (eg: Erlang, Node, Deno of Bun), it would be useful to have a command that gives diagnostic information about the current installation of Gleam. A great example of this is the flutter doctor command which gives information to users about the current Android SDK, Apple Xcode, connected devices and more. More specifically for Gleam, this would be useful to highlight the following development diagnostics: If Erlang is installed, and whether the version is compatible with the current Gleam installation If Node, Deno, or Bun are installed, and whether their versions are compatible with the current Gleam installation Could also output the current installation path, revision commit and more depending on what is considered useful As an example, the tool could be invoked as such: gleam doctor # For basic diagnostics gleam doctor -v # For verbose diagnostics This would also help streamline debugging information

Related to #2697. For example, import woo pub const wibble: Wibble = todo // ^^^^^^ Here, I wanted to use woo.Wibble, but forgot to include module name. Diagnostic in denoted place could include list of types with same from imported modules, like this: Did you mean one of these: - woo.Wibble Moreover, once this is implemented, there could be code action like the one requested in #5750.