Context: I had observed when working on the pybind11 -> nanobind conversions in the MLIR python binding (#1187) that the test_pipeline_error test fails on some platforms because it asserts that the string "Trace" (with a capital "T") is in the error message, but it is not, even though the stack trace was printed. Normally, it would match the string "Trace" in the first line of the stack trace, which contains "llvm::sys::PrintStackTrace". For whatever reason, this line is not always printed out. We can make this test more robust by matching a string not contained within the stack trace itself, but one immediately preceding it, which should always be part of the error message. I've chosen "diagnostic emitted with trace" for this purpose (but I'm happy to take other suggestions).
Description of the Change: Change test from
assert "Trace" in e.value.args[0]
to
assert "diagnostic emitted with trace" in e.value.args[0]
and similarly when asserting that there is no stack trace in the error message.
Context: I had observed when working on the pybind11 -> nanobind conversions in the MLIR python binding (#1187) that the
test_pipeline_error
test fails on some platforms because it asserts that the string"Trace"
(with a capital "T") is in the error message, but it is not, even though the stack trace was printed. Normally, it would match the string"Trace"
in the first line of the stack trace, which contains"llvm::sys::PrintStackTrace"
. For whatever reason, this line is not always printed out. We can make this test more robust by matching a string not contained within the stack trace itself, but one immediately preceding it, which should always be part of the error message. I've chosen"diagnostic emitted with trace"
for this purpose (but I'm happy to take other suggestions).Description of the Change: Change test from
to
and similarly when asserting that there is no stack trace in the error message.
Benefits: More robust test; unblocks #1187.