Same warning printed twice

[okkdev]

My list.concat deprecation warning is being printed twice for the same line/occurrence.

warning: Deprecated value used
    ┌─ /Users/js/Desktop/scream/src/scream.gleam:101:12
    │
101 │     |> list.concat
    │            ^^^^^^^ This value has been deprecated

It was deprecated with this message: Use `list.flatten` instead.

warning: Deprecated value used
    ┌─ /Users/js/Desktop/scream/src/scream.gleam:101:12
    │
101 │     |> list.concat
    │            ^^^^^^^ This value has been deprecated

It was deprecated with this message: Use `list.flatten` instead.

Reproduction

git clone [email protected]:okkdev/scream.git
cd scream/
git checkout dfde544ea477f2e2c27732596c1ab1397612cf41
gleam build

Versions

• Gleam 1.6.1
• macOS 14.6.1
• javascript and erlang target

Log

log.txt

[lpil]

Oh dear! Thank you

[GearsDatapacks]

Looking into this more, it's very strange.

This code prints the warning twice:

import gleam/list

pub fn main() {
  use <- fn(f) { f() }

  list.concat([])
}

However, this doesn't:

import gleam/list

fn usable(f) { f() }

pub fn main() {
  use <- usable

  list.concat([])
}

It only seems to occur if the deprecated value is used inside a use callback, where the right-hand side of the use expression itself is a function literal.

It also prints more times if in several nested use callbacks, doubling each time:

import gleam/list

pub fn main() {
  use <- fn(f) { f() }
  use <- fn(f) { f() }
  use <- fn(f) { f() }

  list.concat([])
  //   ^ This deprecation warning prints 16 times!
}

It does not seem to matter which deprecated value is used.

[lpil]

^ This deprecation warning prints 16 times!

Oops, ahahaha

I presume we're checking for deprecations in the body once before and once after use is expanded?

[GearsDatapacks]

Yes that's what I thought too. Could be related to the recent changes to the ast representation of use, when the desugar code action was introduced. Or this could have always been the case, just never noticed before. I'll test on 1.6.2 and then bisect it later.

[GearsDatapacks]

Ok, so it looks like it was first introduced in 1.5 in d022ff0. My guess is that infer_fn_with_call_context does a second pass over the code and produces duplicate warnings. I'll try and fix this when I get time

[lpil]

d022ff0#diff-892d21f7b2f39e0c5d4ef6a85f69d96b223f6cd4309106ac900cf9c391abb183R2911

Looks like it's doing some wasteful cloning there too? It clones the call arg but discards the original?

[GearsDatapacks]

Ok, so looking into this issue more, it's a bit tricky to figure out a way to get this to work. Basically:

• To infer the arguments, we first infer the left side of the call
• To be able to determine the types of unannotated arguments in an anonymous function, we first infer the arguments

I'll have a play around with it a bit more to try and figure out a solution without breaking any existing behaviour