`TVar` error shows up in release mode but not development mode

[stylewarning]

(Reported by @Jason94.)

I'm getting a strange error when I try to compile a file in release mode. In dev mode, it compiles and runs fine. Here is the error:

; compiling file "/home/jason/programming/workspace/coalton-simple-io/examples/channels-threading.lisp" (written 19 DEC 2025 11:45:43 AM):
; 
; caught COMMON-LISP:ERROR:
;   COMMON-LISP:READ error during COMMON-LISP:COMPILE-FILE:
;   
;     The value
;       #T71411
;     is not of type
;       COALTON-IMPL/TYPECHECKER/TYPES:TYCON
;   
;     (in form starting at line: 34, column: 0, position: 1005)
; 
; compilation unit aborted
;   caught 1 fatal ERROR condition
;   caught 1 ERROR condition

This is the file in question. L102 seems to be the offending line. This compiles:

  (declare sum-file (IO Integer))
  (define sum-file
    (do
     write-data-file
     (_input-chan <- mv:new-empty-chan)
     (_ints-chan <- mv:new-empty-chan)
     (write-line "Forking threads...")
     ;; (fork-thread (reader-thread input-chan))
     ;; ...
     (pure 0)))

But with 102 uncommented, it fails:

  (declare sum-file (IO Integer))
  (define sum-file
    (do
     write-data-file
     (_input-chan <- mv:new-empty-chan)
     (_ints-chan <- mv:new-empty-chan)
     (write-line "Forking threads...")
     (fork-thread (reader-thread _input-chan))
     ;; ...
     (pure 0)))

(And again, that compiles just fine in development mode. The whole thing does.

I'm pretty sure this is a bug, because if it compiles in dev mode it should be compiling in release mode. Plus it shouldn't leak TVars.

The steps I took switching between modes:

1. Switch mode in my init
2. Run rm **/*.fasl in my repo root
3. Delete ~/.cache/common_lisp to force
4. Restart my REPL

[YarinHeffes]

The error is thrown in coalton-impl/codegen/pattern::pattern-constructors-exhaustive-p, because the type argument is a TApp from a TyVar to another TyVar, which unifies to but is more generic than the types of the branch pattern. A crude workaround is to unify the type argument with the branch pattern types in this function.

https://github.com/coalton-lang/coalton/blob/main/src/codegen/pattern.lisp#L184-L213

The error is thrown only in release mode because of the tail form incoalton-impl/codegen/codegen-match:match-emit-branchless-p.

https://github.com/coalton-lang/coalton/blob/main/src/codegen/codegen-match.lisp#L82-L104

In the specific example shared in the issue description, the match statement occurs in a >>= method definition that is marked as inlined. I believe it is either the case that the original method definition is not type checked correctly, or we are omitting a necessary typechecking step that should occur after inlining code from a generic context into a less generic context. A workaround is to remove the (inline) attribute from the method definition.

https://github.com/Jason94/coalton-io/blob/concurrent/src/io-impl/simple-io.lisp#L141-L158

[Jason94]

@YarinHeffes I tried removing the inlining, but I'm still getting the same error. (And I merged your PR. Thank you!)

Should this be enough? Jason94/coalton-io@956c53b

; caught COMMON-LISP:ERROR:
;   COMMON-LISP:READ error during COMMON-LISP:COMPILE-FILE:
;   
;     The value
;       #T70929
;     is not of type
;       COALTON-IMPL/TYPECHECKER/TYPES:TYCON
;   
;     (in form starting at line: 34, column: 0, position: 1005)
; 
; compilation unit aborted
;   caught 1 fatal ERROR condition
;   caught 1 ERROR condition

[YarinHeffes]

Just to be sure, did you restart your Lisp image after removing the inline attribute?

[Jason94]

I did. I also cleared my ~/.cache and removed all my .fasl files. But that was working for you?

[YarinHeffes]

I thought so... Let me double check.

[Jason94]

And it wound up not relying on this code? https://github.com/coalton-lang/coalton/pull/1729/changes

[YarinHeffes]

I just double-checked and you're right. Removing the (inline) doesn't seem to fix it. Sorry about that! We'll have to keep digging.

[stylewarning]

Somewhat good news because I couldn't find a problem with the inliner (except for potentially something small).

[Jason94]

I found a similar release-mode bug that is probably related. Given this monad definition for the STM:

  (define-instance (Monad :io => Monad (STM :io))
    (define >>= flatmap-tx%))

This second test passes in dev mode but hangs in release mode. The first test passes in both. Notably, the first test doesn't require calling >>= at any point:

(define-test test-read-tvar ()
  (let result =
    (run-io!
     (do
      (a <- (new-tvar 0))
      (run-tx (read-tvar a)))))
  (is (== 0 result)))

(define-test test-read-multiple-tvars ()
  (let result =
    (run-io!
     (do
      (write-line "Creating a")
      (a <- (new-tvar 0))
      (write-line "Creating b")
      (b <- (new-tvar "b"))
      (write-line "Running simplified tx")
      (run-tx (read-tvar a))
      (write-line "Running manual >>=")
      (run-tx
       (>>= (read-tvar a)
            (fn (a-val)
              (>>= (read-tvar b)
                   (fn (b-val)
                     (pure (Tuple a-val b-val)))))))
      (write-line "Running do tx")
      (run-tx
       (do
         (tx-io!% (write-line "Reading from a"))
         (a-val <- (read-tvar a))
         (tx-io!% (write-line "Reading from b"))
         (b-val <- (read-tvar b))
         (tx-io!% (write-line "Returning tx"))
         (pure (tuple a-val b-val)))))))
  (is (== (Tuple 0 "b") result)))

Logs:

COALTON-IO/TESTS/CONC/STM-FIASCO (Suite)
  TEST-READ-TVAR..........................................................[ OK ]
  TEST-READ-MULTIPLE-TVARSCreating a
Creating b
Running simplified tx
Running manual >>=

The logs show that:
(1) The first test passes
(2) In the second test, the simplified tx ((run-tx (read-tvar a))) that doesn't require any calls to >>= passes.
(3) However, in the second test, the tx that requires >>= hangs:

      (run-tx
       (>>= (read-tvar a)
            (fn (a-val)
              (>>= (read-tvar b)
                   (fn (b-val)
                     (pure (Tuple a-val b-val)))))))

I expanded this myself, so it definitely isn't caused by do itself.

The test passes if I change the definition of >>= to not use the "mere redefine" style:

  (define-instance (Monad :io => Monad (STM :io))
    (inline)
    (define (>>= m f)
      (flatmap-tx% m f)))

Log:

#<PACKAGE "COALTON-IO/TESTS/CONC/STM-FIASCO">
COALTON-IO/TESTS/CONC/STM-FIASCO> (run-package-tests)
COALTON-IO/TESTS/CONC/STM-FIASCO (Suite)
  TEST-READ-TVAR..........................................................[ OK ]
  TEST-READ-MULTIPLE-TVARSCreating a
Creating b
Running simplified tx
Running manual >>=
Calling flatmap-tx%
Flatmap-Tx% inner
Calling flatmap-tx%
Flatmap-Tx% inner
Running do tx
Calling flatmap-tx%
Flatmap-Tx% inner
Reading from a
Calling flatmap-tx%
Flatmap-Tx% inner
Calling flatmap-tx%
Flatmap-Tx% inner
Reading from b
Calling flatmap-tx%
Flatmap-Tx% inner
Calling flatmap-tx%
Flatmap-Tx% inner
Returning tx
..........................................................................[ OK ]

---

So that's a lot, but the short end of it is that:

1. do is not the problem
2. inline is not the problem
3. The problem seems to be caused by defining monad instances, possibly other instances as well, like this:

  (define-instance (Monad :io => Monad (STM :io))
    (define >>= flatmap-tx%))

Edit: Actually, on further editing, this might be a separate - but possibly related - issue. Instead of hanging, the original issue threw a typecheck failure. Also, I checked the main IO monad definition and it doesn't use that shortcutting for any of its definitions.