Describe the bug
The following is linked to #1615 .
CC @proppy and @richmckeever
After rebasing the changes from #1654 onto upstream XLS we noticed failing checks during IR generation for ZstdDecoder proc. This did not happen on older XLS version. With the help of git bisect I've found out that 9081e20 is the first commit that breaks the IR generation for the proc. I double checked all the procs in zstd_decoder.x towards incorrect use of the parameters but I wasn't able to find anything that could cause the issue.
To Reproduce
Steps to reproduce the behavior:
Checkout on the branch from the forked repo
Execute the command bazel build -c opt //xls/modules/zstd:zstd_dec_verilog
Observe nominal_type_dims_by_identifier_.empty() check failure:
F1009 15:41:26.389415 1548522 type.cc:617] Check failed: nominal_type_dims_by_identifier_.empty()
*** Check failure stack trace: ***
@ 0x5aff48c6ca34 absl::lts_20240116::log_internal::LogMessage::SendToLog()
@ 0x5aff48c6c708 absl::lts_20240116::log_internal::LogMessage::Flush()
@ 0x5aff48c6cdd9 absl::lts_20240116::log_internal::LogMessageFatal::~LogMessageFatal()
@ 0x5aff48a67856 xls::dslx::StructType::AddNominalTypeDims()
@ 0x5aff48a6cff7 xls::dslx::MetaType::AddNominalTypeDims()
@ 0x5aff488bb9c0 xls::dslx::(anonymous namespace)::DeduceVisitor::HandleTypeRefTypeAnnotation()
@ 0x5aff48aaceab xls::dslx::TypeRefTypeAnnotation::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff488cb072 xls::dslx::(anonymous namespace)::DeduceArrayTypeAnnotation()
@ 0x5aff488b9a4b xls::dslx::(anonymous namespace)::DeduceVisitor::HandleArrayTypeAnnotation()
@ 0x5aff48aacefb xls::dslx::ArrayTypeAnnotation::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff488e21c6 xls::dslx::DeduceConstantArray()
@ 0x5aff488c0abb xls::dslx::(anonymous namespace)::DeduceVisitor::HandleConstantArray()
@ 0x5aff48aac92b xls::dslx::ConstantArray::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff489aac2c xls::dslx::DeduceCtx::DeduceAndResolve()
@ 0x5aff488c265f xls::dslx::(anonymous namespace)::DeduceVisitor::HandleLet()
@ 0x5aff48aae7bb xls::dslx::Let::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff488b8e74 xls::dslx::(anonymous namespace)::DeduceVisitor::HandleStatement()
@ 0x5aff48aae61b xls::dslx::Statement::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff488bd4ab xls::dslx::(anonymous namespace)::DeduceVisitor::HandleStatementBlock()
@ 0x5aff48aadebb xls::dslx::StatementBlock::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff48900352 xls::dslx::TypecheckInvocation()
@ 0x5aff488ac658 std::__1::__function::__func<>::operator()()
@ 0x5aff488e9717 xls::dslx::DeduceInstantiation()
@ 0x5aff488f1771 xls::dslx::DeduceSpawn()
@ 0x5aff488c67db xls::dslx::(anonymous namespace)::DeduceVisitor::HandleSpawn()
@ 0x5aff48aad7ab xls::dslx::Spawn::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff488b8e74 xls::dslx::(anonymous namespace)::DeduceVisitor::HandleStatement()
@ 0x5aff48aae61b xls::dslx::Statement::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff488bd4ab xls::dslx::(anonymous namespace)::DeduceVisitor::HandleStatementBlock()
@ 0x5aff48aadebb xls::dslx::StatementBlock::Accept()
@ 0x5aff488b40e1 xls::dslx::Deduce()
@ 0x5aff488ac395 std::__1::__function::__func<>::operator()()
@ 0x5aff489a9df8 xls::dslx::DeduceCtx::Deduce()
@ 0x5aff489aac2c xls::dslx::DeduceCtx::DeduceAndResolve()
@ 0x5aff488b111d xls::dslx::TypecheckFunction()
@ 0x5aff488a92ed xls::dslx::TypecheckModule()
@ 0x5aff4882dc51 xls::dslx::ConvertFilesToPackage()
@ 0x5aff487e0e00 main
@ 0x75e67fc29d90 (unknown)
Target //xls/modules/zstd:zstd_dec_verilog failed to build
Checkout on the branch from modules/zstd: Rework ZSTD Decoder #1654 or revert 9081e20 (will require solving a conflict)
Repeat the bazel build command: bazel build -c opt //xls/modules/zstd:zstd_dec_verilog
Observe correct IR and verilog generation for the ZstdDecoder proc.
Expected behavior
Toolchain should be able to generate IR for the provided ZstdDecoder proc .
Additional context
This is a blocker for #1654 and as a consequence also for #1211 .
Describe the bug
The following is linked to #1615.
CC @proppy and @richmckeever
After rebasing the changes from #1654 onto upstream XLS we noticed failing checks during IR generation for
ZstdDecoderproc. This did not happen on older XLS version. With the help ofgit bisectI've found out that 9081e20 is the first commit that breaks the IR generation for the proc. I double checked all the procs inzstd_decoder.xtowards incorrect use of the parameters but I wasn't able to find anything that could cause the issue.To Reproduce
Steps to reproduce the behavior:
bazel build -c opt //xls/modules/zstd:zstd_dec_verilognominal_type_dims_by_identifier_.empty()check failure:bazel build -c opt //xls/modules/zstd:zstd_dec_verilogZstdDecoderproc.Expected behavior
Toolchain should be able to generate IR for the provided
ZstdDecoderproc .Additional context
This is a blocker for #1654 and as a consequence also for #1211.