#LSP issue

1 messages · Page 1 of 1 (latest)

warped sand
#

Hi all, I keep running into an issue with LSP where is says I both meet and don't meet a given typing. (See picture)
I have narrowed it down to the following line of code: row |> dynamic.from |> decode.run(decoder) |> callback but I don't know if this is me being stupid with type generics or if this is a LSP bug.

Any help would be appreciated.

The following code triggers this issue:

import gleam/dict
import gleam/dynamic
import gleam/dynamic/decode
import gleam/list
import gleam/option
import gpostgres/query

pub type Reader {
  Reader(rows: List(List(dynamic.Dynamic)), columns: List(String))
}

fn transform_row(row: List(dynamic.Dynamic), columns: List(String)) {
  row |> list.zip(columns, _) |> dict.from_list()
}

pub fn next(
  reader: Reader,
) -> #(option.Option(dict.Dict(String, dynamic.Dynamic)), Reader) {
  case reader.rows {
    [] -> #(option.None, reader)
    [row] -> #(
      row |> transform_row(reader.columns) |> option.Some,
      Reader(rows: [], columns: reader.columns),
    )
    [row, ..rows] -> #(
      row |> transform_row(reader.columns) |> option.Some,
      Reader(rows: rows, columns: reader.columns),
    )
  }
}

pub type DecodeOption(a) {
  Stop
  Ingore
  Accept(a)
}

fn do_decode(
  reader: Reader,
  decoder: decode.Decoder(a),
  callback: fn(Result(a, List(decode.DecodeError))) -> DecodeOption(a),
  state: List(a),
) {
  case next(reader) {
    #(option.Some(row), new_reader) ->
      case row |> dynamic.from |> decode.run(decoder) |> callback {
        Stop -> state
        Ingore -> do_decode(new_reader, decoder, callback, state)
        Accept(value) ->
          do_decode(new_reader, decoder, callback, [value, ..state])
      }
    #(option.None, _) -> state
  }
}

pub fn decode(
  reader: Reader,
  decoder: decode.Decoder(a),
  callback: fn(Result(a, List(decode.DecodeError))) -> DecodeOption(a),
) -> List(a) {
  do_decode(reader, decoder, callback, [])
}
X0cyblx.png
#

I am on gleam 1.9.1 windows btw.

#

Upon specifying a return type for do_decode this issue disappears. -> List(a).

hazy vault
#

We haven't managed to fix it yet unfortunately

stone depot
#

Typically one write annotations for functions so this doesn't come up in practice

#

Very annoying though! Need to fix this

warped sand
#

Anyway thanks for the reply, could we maybe just check if the stringified types are the same and if so add a hint?