search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
96.72k stars 12.5k forks source link

regression: `panic!` and RUST_BACKTRACE=1 Show Wrong & Non-Informative Function Names when Unwinding #78713

Open DK26 opened 3 years ago

DK26 commented 3 years ago

As I'm learning the language from a book ("The Complete Rust Programming Reference Guide" p. 229-230), and was executing the panic! macro in a multi-thread environment, I've noticed the unwinding from the book is different from the one I've got where the one I've got is not informative or helpful, and seems wrong where the one in book seems to be OK.

Code

I tried this code:

// panic_unwinding.rs

use std::thread;

fn alice() -> thread::JoinHandle<()> {
    thread::spawn(move || {
        bob();
    })
}

fn bob() {
    malice();
}

fn malice() {
    panic!("malice is panicking!");
}

fn main() {

    let child = alice();
    let _ = child.join();

    bob();
    println!("This is unreachable code");

}

I expected the backtrace to include the function names as they were called, all the way from the entry point of the threads.

Instead, all functions were named the same: (env: RUST_BACKTRACE=1)

thread '<unnamed>' panicked at 'malice is panicking!', .\panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', .\panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Version it worked on

I don't know from when is the regression. The book is using an old version of Rust: 1.32.0

Version with regression

I use the most current version: Rust 1.47.0

rustc --version --verbose:

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-pc-windows-msvc
release: 1.47.0
LLVM version: 11.0

ghost commented 3 years ago

Simply testing the example code as provided I find,

thread '<unnamed>' panicked at 'malice is panicking', src/main.rs:14:5
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:497
   1: test_crate::malice
             at ./src/main.rs:14
   2: test_crate::bob
             at ./src/main.rs:10
   3: test_crate::alice::{{closure}}
             at ./src/main.rs:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking', src/main.rs:14:5
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:497
   1: test_crate::malice
             at ./src/main.rs:14
   2: test_crate::bob
             at ./src/main.rs:10
   3: test_crate::main
             at ./src/main.rs:21
   4: core::ops::function::FnOnce::call_once
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

, under, 

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.47.0
LLVM version: 11.0

, so this might be restricted to O-windows or is that already known?

apiraino commented 3 years ago

Bisected to nightly-2020-08-09

found 13 bors merge commits in the specified range
  commit[0] 2020-08-07UTC: Auto merge of #75255 - davidtwco:polymorphisation-symbol-mangling-v0-upvar-closures, r=lcnr
  commit[1] 2020-08-07UTC: Auto merge of #75071 - ssomers:btree_cleanup_5, r=Mark-Simulacrum
  commit[2] 2020-08-08UTC: Auto merge of #75048 - eggyal:force-no-tco-start-backtrace-frame, r=Mark-Simulacrum
  commit[3] 2020-08-08UTC: Auto merge of #74877 - lcnr:min_const_generics, r=oli-obk
  commit[4] 2020-08-08UTC: Auto merge of #75276 - JohnTitor:rollup-rz4hs0w, r=JohnTitor
  commit[5] 2020-08-08UTC: Auto merge of #74932 - nnethercote:rm-ast-session-globals, r=petrochenkov
  commit[6] 2020-08-08UTC: Auto merge of #75257 - ssomers:btree_74762_again, r=Mark-Simulacrum
  commit[7] 2020-08-08UTC: Auto merge of #75282 - RalfJung:miri-black-box, r=oli-obk
  commit[8] 2020-08-08UTC: Auto merge of #74289 - lzutao:unroll, r=LukasKalbertodt
  commit[9] 2020-08-08UTC: Auto merge of #74533 - nikic:issue-74425, r=eddyb
  commit[10] 2020-08-08UTC: Auto merge of #75260 - davidtwco:polymorphization-promoted-substs, r=lcnr
  commit[11] 2020-08-08UTC: Auto merge of #75163 - canova:map_into_keys_values, r=dtolnay
  commit[12] 2020-08-08UTC: Auto merge of #75271 - cuviper:array-iter, r=LukasKalbertodt
ERROR: no commits between 09f4c9f5082f78b0adcee83d3ab4337e000cd28e and 
    ceedf1d5febd65b012b8bcd513d70a0a6a091210 within last 167 days

(if I've done correctly), bisected with script:

$ RUST_SRC_REPO=~/rust cargo-bisect-rustc --preserve --start=2020-06-01 --end=2020-10-08 --script=./test.sh

$ cat ./test.sh
#!/bin/sh
RUST_BACKTRACE=1 cargo run 2>&1 | grep __libc_start_main
apiraino commented 3 years ago

Assigning priority as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

@rustbot label -I-prioritize +P-medium

eggyal commented 3 years ago

I think #75048 was the likely culprit.

eggyal commented 3 years ago

Is the backtrace correctly described with RUST_BACKTRACE=full?

apiraino commented 3 years ago

Is the backtrace correctly described with RUST_BACKTRACE=full?

@eggyal In my local test with RUST_BACKTRACE=full seems to print the full stacktrace as expected. (I don't have access to the reference mentioned by the issue reporter so I cannot compare)

m-ou-se commented 3 years ago

Has this issue been fixed?

LukasKalbertodt commented 3 years ago

The issue still occurs with 1.54 on Windows.

C:\Users\lukas>rustc +1.47.0 panic_unwinding.rs

C:\Users\lukas>set RUST_BACKTRACE=1

C:\Users\lukas>panic_unwinding.exe
thread '<unnamed>' panicked at 'malice is panicking!', panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

C:\Users\lukas>rustc +1.54.0 panic_unwinding.rs

C:\Users\lukas>panic_unwinding.exe
thread '<unnamed>' panicked at 'malice is panicking!', panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
m-ou-se commented 3 years ago

Thanks for testing it! Marking this as a Windows issue. I've tested it on both Linux and Mac, where it works fine.

m-ou-se commented 3 years ago

It also works fine on x86_64-pc-windows-gnu in wine.

semicoleon commented 2 years ago

I can still reproduce this on 1.61.0 but with a weird caveat I haven't seen mentioned anywhere: it works correctly through cargo but not rustc directly?

cargo

``` >cargo run Finished dev [unoptimized + debuginfo] target(s) in 0.01s Running `target\debug\windows-panic-trace.exe` thread '' panicked at 'malice is panicking!', src\main.rs:16:5 stack backtrace: 0: std::panicking::begin_panic at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\std\src\panicking.rs:616 1: windows_panic_trace::malice at .\src\main.rs:16 2: windows_panic_trace::bob at .\src\main.rs:12 3: windows_panic_trace::alice::closure$0 at .\src\main.rs:7 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. thread 'main' panicked at 'malice is panicking!', src\main.rs:16:5 stack backtrace: 0: std::panicking::begin_panic at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\std\src\panicking.rs:616 1: windows_panic_trace::malice at .\src\main.rs:16 2: windows_panic_trace::bob at .\src\main.rs:12 3: windows_panic_trace::main at .\src\main.rs:23 4: core::ops::function::FnOnce::call_once > at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\core\src\ops\function.rs:227 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: process didn't exit successfully: `target\debug\windows-panic-trace.exe` (exit code: 101) ```

rustc

``` > rustc .\src\main.rs > .\main.exe thread '' panicked at 'malice is panicking!', .\src\main.rs:16:5 stack backtrace: 0: std::panicking::begin_panic 1: main::alice::{{closure}} 2: main::alice::{{closure}} 3: main::alice::{{closure}} note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. thread 'main' panicked at 'malice is panicking!', .\src\main.rs:16:5 stack backtrace: 0: std::panicking::begin_panic 1: main::alice::{{closure}} 2: main::alice::{{closure}} 3: main::alice::{{closure}} 4: core::ops::function::FnOnce::call_once note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. ```

Also RUST_BACKTRACE=full does not seem to resolve the problem

eggyal commented 2 years ago

it works correctly through cargo but not rustc directly?

> rustc .\src\main.rs

If you don't specify -C debuginfo, it defaults to 0 (no debug info). cargo's default dev profile uses debuginfo=2 (full debug info). That's the likely difference.

semicoleon commented 2 years ago

Yup, that did the trick

> rustc -C debuginfo=2 .\src\main.rs
> .\main.exe
thread '<unnamed>' panicked at 'malice is panicking!', .\src\main.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\std\src\panicking.rs:616
   1: main::malice
             at .\src\main.rs:16
   2: main::bob
             at .\src\main.rs:12
   3: main::alice::closure$0
             at .\src\main.rs:7
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', .\src\main.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic<str>
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\std\src\panicking.rs:616
   1: main::malice
             at .\src\main.rs:16
   2: main::bob
             at .\src\main.rs:12
   3: main::main
             at .\src\main.rs:23
   4: core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
             at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e\library\core\src\ops\function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
ChrisDenton commented 1 year ago

So to confirm, this is considered fixed? Or do we still need to handle the debuginfo=0 situation better?

ChrisDenton commented 1 year ago

This still happens unless -C debuginfo is set to 1 or higher (which cargo's dev profile will do by default).

@wesleywiser suggests that:

We should perhaps consider adjusting the default compiler behavior to include basic debuginfo unless the user specifically asks for none

joshtriplett commented 1 year ago

@ChrisDenton Do you mean for the release profile? I don't think we should be adding any debuginfo to release builds unless the user requests that.

ChrisDenton commented 1 year ago

I don't personally have a strong opinion here tbh but I think that was what @wesleywiser was saying. I could be mistaken though.

ChrisDenton commented 1 year ago

Ok, just to clarify the issue here. When using debuginfo=0 no new debuginfo is created but the prebuilt std does include debuginfo so a pdb file is created anyway.

Something about this seems to confuse the backtrace. Our backtrace-rs defers to dbghelp.dll so this is probably either a bug in the compiler or in dbghelp.dll. It could also be a problem with the way backtrace-rs uses dbghelp.dll.

Here's a demo of the issue. The debuginfo=0 seems to get messed up when not in std functions.

> cat panic.rs
fn main() {
    panic!("Oh no!");
}
debuginfo=0, strip=debuginfo ``` > rustc +nightly panic.rs -C debuginfo=0 -C strip=debuginfo && ./panic thread 'main' panicked at 'Oh no!', panic.rs:2:5 stack backtrace: 0: 0x7ff661d7773c - 1: 0x7ff661d8626b - 2: 0x7ff661d759a1 - 3: 0x7ff661d774eb - 4: 0x7ff661d7953a - 5: 0x7ff661d7918f - 6: 0x7ff661d79bee - 7: 0x7ff661d71181 - 8: 0x7ff661d71059 - 9: 0x7ff661d710ff - 10: 0x7ff661d7169c - 11: 0x7ff661d71226 - 12: 0x7ff661d71069 - 13: 0x7ff661d710bc - 14: 0x7ff661d73918 - 15: 0x7ff661d71097 - 16: 0x7ff661d716b9 - 17: 0x7ff661d89c00 - 18: 0x7ffbe5c926ad - BaseThreadInitThunk 19: 0x7ffbe69caa68 - RtlUserThreadStart ```
debuginfo=0 ``` > rustc +nightly panic.rs -C debuginfo=0 && ./panic thread 'main' panicked at 'Oh no!', panic.rs:2:5 stack backtrace: 0: 0x7ff74631773c - std::sys_common::backtrace::_print::impl$0::fmt at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:44 1: 0x7ff74632626b - core::fmt::rt::Argument::fmt at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\core\src\fmt\rt.rs:138 2: 0x7ff74632626b - core::fmt::write at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\core\src\fmt\mod.rs:1094 3: 0x7ff7463159a1 - std::io::Write::write_fmt at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\io\mod.rs:1714 4: 0x7ff7463174eb - std::sys_common::backtrace::_print at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:47 5: 0x7ff7463174eb - std::sys_common::backtrace::print at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:34 6: 0x7ff74631953a - std::panicking::default_hook::closure$1 at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:269 7: 0x7ff74631918f - std::panicking::default_hook at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:288 8: 0x7ff746319bee - std::panicking::rust_panic_with_hook at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:705 9: 0x7ff746311181 - std::rt::lang_start::hd50dd812db788f81 10: 0x7ff746311059 - __ImageBase 11: 0x7ff7463110ff - std::rt::lang_start::hd50dd812db788f81 12: 0x7ff74631169c - std::rt::lang_start::hd50dd812db788f81 13: 0x7ff746311226 - std::rt::lang_start::hd50dd812db788f81 14: 0x7ff746311069 - __ImageBase 15: 0x7ff7463110bc - std::rt::lang_start::hd50dd812db788f81 16: 0x7ff746313918 - std::rt::lang_start_internal::closure$2 at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\rt.rs:148 17: 0x7ff746313918 - std::panicking::try::do_call at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:500 18: 0x7ff746313918 - std::panicking::try at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:464 19: 0x7ff746313918 - std::panic::catch_unwind at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panic.rs:142 20: 0x7ff746313918 - std::rt::lang_start_internal at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\rt.rs:148 21: 0x7ff746311097 - std::rt::lang_start::hd50dd812db788f81 22: 0x7ff7463116b9 - main 23: 0x7ff746329c00 - invoke_main at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78 24: 0x7ff746329c00 - __scrt_common_main_seh at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 25: 0x7ffbe5c926ad - BaseThreadInitThunk 26: 0x7ffbe69caa68 - RtlUserThreadStart ```
debuginfo=1 ``` > rustc +nightly panic.rs -C debuginfo=1 && ./panic thread 'main' panicked at 'Oh no!', panic.rs:2:5 stack backtrace: 0: 0x7ff6014a773c - std::sys_common::backtrace::_print::impl$0::fmt at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:44 1: 0x7ff6014b626b - core::fmt::rt::Argument::fmt at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\core\src\fmt\rt.rs:138 2: 0x7ff6014b626b - core::fmt::write at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\core\src\fmt\mod.rs:1094 3: 0x7ff6014a59a1 - std::io::Write::write_fmt at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\io\mod.rs:1714 4: 0x7ff6014a74eb - std::sys_common::backtrace::_print at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:47 5: 0x7ff6014a74eb - std::sys_common::backtrace::print at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\sys_common\backtrace.rs:34 6: 0x7ff6014a953a - std::panicking::default_hook::closure$1 at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:269 7: 0x7ff6014a918f - std::panicking::default_hook at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:288 8: 0x7ff6014a9bee - std::panicking::rust_panic_with_hook at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:705 9: 0x7ff6014a1181 - std::panicking::begin_panic::closure$0 > at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\panicking.rs:626 10: 0x7ff6014a1059 - std::sys_common::backtrace::__rust_end_short_backtrace >,never$> at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\sys_common\backtrace.rs:151 11: 0x7ff6014a1059 - std::sys_common::backtrace::__rust_end_short_backtrace >,never$> at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\sys_common\backtrace.rs:151 12: 0x7ff6014a10ff - std::panicking::begin_panic > at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\panicking.rs:625 13: 0x7ff6014a169c - panic::main at Z:\test\panic.rs:2 14: 0x7ff6014a1226 - core::ops::function::FnOnce::call_once > at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\core\src\ops\function.rs:250 15: 0x7ff6014a1069 - std::sys_common::backtrace::__rust_begin_short_backtrace > at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\sys_common\backtrace.rs:135 16: 0x7ff6014a1069 - std::sys_common::backtrace::__rust_begin_short_backtrace > at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\sys_common\backtrace.rs:135 17: 0x7ff6014a10bc - std::rt::lang_start::closure$0 > at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\rt.rs:166 18: 0x7ff6014a3918 - std::rt::lang_start_internal::closure$2 at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\rt.rs:148 19: 0x7ff6014a3918 - std::panicking::try::do_call at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:500 20: 0x7ff6014a3918 - std::panicking::try at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panicking.rs:464 21: 0x7ff6014a3918 - std::panic::catch_unwind at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\panic.rs:142 22: 0x7ff6014a3918 - std::rt::lang_start_internal at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29/library\std\src\rt.rs:148 23: 0x7ff6014a1097 - std::rt::lang_start > at /rustc/4c8bb79d9f565115637cc6da739f8389e79f3a29\library\std\src\rt.rs:165 24: 0x7ff6014a16b9 - main 25: 0x7ff6014b9c00 - invoke_main at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78 26: 0x7ff6014b9c00 - __scrt_common_main_seh at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 27: 0x7ffbe5c926ad - BaseThreadInitThunk 28: 0x7ffbe69caa68 - RtlUserThreadStart ```
ChrisDenton commented 1 year ago

Add the T-compiler tag in case they want to look at this.