Non-exhaustive pattern error when using multiple lambdas inside constructor/function call

[ReubenJ]

Multiple calls to the @λ inside a constructor or method call seem to produce an erroneous matching non-exhaustive error.

julia> struct SomeStruct
                   one_lambda
                   another_lambda
               end

julia> SomeStruct(@λ begin
           _ => true
       end, @λ begin
           _ => true
       end)
ERROR: LoadError: matching non-exhaustive, at #= ~/.julia/packages/MLStyle/SLOsr/src/StandardPatterns/LambdaCases.jl:27 =#
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:35
 [2] gen_lambda(cases::Any, source::LineNumberNode, mod::Module)
   @ MLStyle.LambdaCases ~/.julia/packages/MLStyle/SLOsr/src/StandardPatterns/LambdaCases.jl:49
 [3] var"@λ"(__source__::LineNumberNode, __module__::Module, cases::Any)
   @ MLStyle.LambdaCases ~/.julia/packages/MLStyle/SLOsr/src/StandardPatterns/LambdaCases.jl:78
in expression starting at REPL[5]:1

If I instead place the calls to the @λ macro outside of the constructor, no matching error is produced.

julia> one_lambda = @λ begin
           _ => true
       end
##λ#226 (generic function with 1 method)

julia> another_lambda = @λ begin
           _ => true
       end
##λ#230 (generic function with 1 method)

julia> SomeStruct(one_lambda, another_lambda)
SomeStruct(var"##λ#226", var"##λ#230")

I would expect the behavior to be the same for both cases.

Interestingly, the error does not occur with a single @λ call:

julia> struct SomeOtherStruct
          one_lambda
       end

julia> SomeOtherStruct(@λ begin
           _ => true
       end)
SomeOtherStruct(var"##λ#234")

Manifest to reproduce

julia_version = "1.10.3"
manifest_format = "2.0"
project_hash = "06dc1a8f7f58f18641326ca54395a788118a84d3"

[[deps.MLStyle]]
git-tree-sha1 = "bc38dff0548128765760c79eb7388a4b37fae2c8"
uuid = "d8e11817-5142-5d16-987a-aa16d5891078"
version = "0.4.17"

[ReubenJ]

This can be avoided by using parentheses:

SomeStruct((@λ begin
           _ => true
       end), (@λ begin
           _ => true
       end))

Without the parentheses, the first macro also consumes the call to the second one. I'm not familiar enough with building macros to say whether this is normal and/or avoidable.