Project tool: crash on some caliptra-rtl files

[hzeller]

Project:
https://github.com/chipsalliance/caliptra-rtl

The symbol table has some checks that trigger on invariants: getting more than expected number of siblings in an vector. The corresponding vector needs to have enough reserve()'d, but hasn't.

Will update the smoke test soon with this project.

symbol_table.cc:153] Check failed: siblings.size() < siblings.capacity() (1 vs. 1) 
Reallocation would invalidate pointers to reference nodes at:
{ (.soc_ifc_status_driver_bfm -> <unresolved>)
  { (::MONITOR_BFM_BIND_T[parameter] -> <unresolved>) }
}
While attempting to add child:
.soc_ifc_status_monitor_bfm -> <unresolved>
Fix: pre-allocate child nodes.
*** Check failure stack trace: ***
    @     0x564579e1f469  absl::log_internal::LogMessage::SendToLog()
    @     0x564579e1f8d9  absl::log_internal::LogMessageFatal::~LogMessageFatal()
    @     0x564579dba423  verilog::CheckedNewChildReferenceNode()
    @     0x564579dbb3ab  verilog::DependentReferences::PushReferenceComponent()
    @     0x564579dbc1d6  verilog::SymbolTable::Builder::HandleIdentifier()
    @     0x564579dbc684  verilog::SymbolTable::Builder::Visit()

[hzeller]

This is inside the symbol table, assigning to Grzegorz .

[hzeller]

Here is the change to smoke tests #1947

[IEncinas10]

I'm facing similar crashes when trying to use the LSP to go-to-definition. In one case, the error is the same as in the issue description, but after choosing a random file from caliptra-rtl I get a new one:

[DEBUG][2024-01-27 12:47:08] .../lua/vim/lsp.lua:1391	"LSP[verible]"	"client.request"	1	"textDocument/definition"	{  position = {    character = 5,    line = 68  },  textDocument = {    uri = "file:///home/ier/cosas/caliptra-rtl/src/ecc/rtl/ecc_pe.sv"  }}	<function 1>	1
[DEBUG][2024-01-27 12:47:08] .../vim/lsp/rpc.lua:284	"rpc.send"	{  id = 2,  jsonrpc = "2.0",  method = "textDocument/definition",  params = {    position = {      character = 5,      line = 68    },    textDocument = {      uri = "file:///home/ier/cosas/caliptra-rtl/src/ecc/rtl/ecc_pe.sv"    }  }}
[DEBUG][2024-01-27 12:47:09] .../vim/lsp/rpc.lua:284	"rpc.send"	{  jsonrpc = "2.0",  method = "$/cancelRequest",  params = {    id = 2  }}
[ERROR][2024-01-27 12:47:09] .../vim/lsp/rpc.lua:734	"rpc"	"/usr/bin/verible-verilog-ls"	"stderr"	"F0127 12:47:09.208507   93093 symbol_table.cc:1180] Check failed: 'declaration_type_info_' Must be non-null\n"

I know it is a pretty vague question but do these issues require significant work and understanding of the symbol table? If they aren't too complex I'd be happy to try my luck (ideally solving the issue, but if that is not possible at least stopping the crashes). Any pointers would be greatly appreciated :)

[hzeller]

I have not addressed the original issue yet, but I have made some robustness improvements in the language server go-to-defintion routines over the last week.

If you find issues with the langauge server in particular what involves go-to-definition, find-references and (new 🎉 ) rename-symbol please file an issue with the project you were looking at (ideally with the git hash version) and what sequence led up to that.

[hzeller]

ah, nevermind, can reproduce the declaration_type_info_ check failure:

 verible-verilog-project symbol-table-refs src/doe/formal/properties/fv_doe_decryption/fv_doe_decrypt.sv
F0201 21:01:53.198811 1531655 symbol_table.cc:1180] Check failed: 'declaration_type_info_' Must be non-null
*** Check failure stack trace: ***
    @           0x499b28  absl::lts_20230802::log_internal::LogMessage::SendToLog()
    @           0x49a029  absl::lts_20230802::log_internal::LogMessageFatal::~LogMessageFatal()
    @           0x4121c9  absl::lts_20230802::log_internal::DieBecauseNull()
    @           0x434eef  verilog::SymbolTable::Builder::EmplaceTypedElementInCurrentScope()
    @           0x436c12  verilog::SymbolTable::Builder::Visit()
    @           0x48bc31  verible::TreeContextVisitor::Visit()
    @           0x436c23  verilog::SymbolTable::Builder::Visit()
    @           0x48bc31  verible::TreeContextVisitor::Visit()
    @           0x436c23  verilog::SymbolTable::Builder::Visit()
    @           0x48bc31  verible::TreeContextVisitor::Visit()
    @           0x436c23  verilog::SymbolTable::Builder::Visit()
    @           0x48bc31  verible::TreeContextVisitor::Visit()
    @           0x436c23  verilog::SymbolTable::Builder::Visit()
    @           0x48bc31  verible::TreeContextVisitor::Visit()
    @           0x436c23  verilog::SymbolTable::Builder::Visit()
    @           0x48bc31  verible::TreeContextVisitor::Visit()
    @           0x43719f  verilog::SymbolTable::Builder::Visit()
    @           0x48bc31  verible::TreeContextVisitor::Visit()
    @           0x436c23  verilog::SymbolTable::Builder::Visit()
    @           0x42fb9b  verilog::BuildSymbolTable()
    @           0x42fcad  verilog::ParseFileAndBuildSymbolTable()
    @           0x42ff96  verilog::SymbolTable::BuildSingleTranslationUnit()
    @           0x41a9f2  ResolveAndShowSymbolReferences()
    @           0x414c1d  std::_Function_handler<>::_M_invoke()
    @           0x4145b7  main

[IEncinas10]

I didn't file any issues as I wasn't sure they would be helpful, I tried making a reduced test-case but couldn't. I also wonder whether some problems come from not being able to parse some code.

I'll try to have a look because all this LSP thing is great for users. I saw those old PRs that you rebased and merged, thanks for that!