You’re getting a segmentation fault because not every symbols has ObjectEntityDetails (only those that represent objects do). So sometimes object is null. If you check for object being nullptr before dereferencing it your code wouldn’t crash.
There are two other kinds of details that also have init(): ProcEntityDetails and TypeParamDetails. If you’re interested in initialization of those kinds of symbols as well, you’ll need to check for those using detailsIf or std::visit over the details of the symbol.
One more thing: If you are only checking constraints and not doing things that affect what ends up in symbols, check-declarations.cc might be a better place for your change. resolve-names.cc is for building up the symbols and it checks constraints along the way. The checks in check-declarations.cc happen after that and are ones that can be done by just looking at the symbol table without any context from the parse tree.
I have another question:
So I would imagine that a variable initialized with DATA block could be checked as: object->init().has_value()
But this code :
BLOCK DATA DBAXES
DATA I,J,K,ifail /1,2,3,4/
END BLOCK DATA
When I run does not accuse ifail as being initialized.
Looking at the code I can see that if a variable is initialized as DATA it is only saved as std::list<common::Indirectionparser::DataStmtValue>, is this correct? I mean is my thought correct?
You are right, a variable initialized with a DATA statement should have an initial value returned by init() and that comes from DataStmtValue. That’s not implemented yet, whether the DATA statement is in a BLOCK DATA program unit or not.
Somewhere in resolve-names.cc we need to recognize DataStmtSet and walk through the lists of DataStmtObject and DataStmtValue and set the initialization of the objects from the values.
So, do we know when this will be implemented.
If there is no plan to someone implement it any time soon.
Can I do the work, as I need this to finish the Block Data checks?