UQ-PAC / BASIL

Apache License 2.0
8 stars 0 forks source link

Call fallthrough assertion #199

Closed l-kent closed 3 months ago

l-kent commented 6 months ago

The Call trait requiring that a returnTarget Block must already have a parent Procedure is impractical.

https://github.com/UQ-PAC/bil-to-boogie-translator/blob/b6a2409f60b977985ee0c97959cdcfe04bdb35f0/src/main/scala/ir/Statement.scala#L133-L142

This is an issue for handleUnidentifedIndirectCall: https://github.com/UQ-PAC/bil-to-boogie-translator/blob/b6a2409f60b977985ee0c97959cdcfe04bdb35f0/src/main/scala/translating/GTIRBToIR.scala#L352-L398

https://github.com/UQ-PAC/bil-to-boogie-translator/blob/b6a2409f60b977985ee0c97959cdcfe04bdb35f0/src/main/scala/translating/GTIRBToIR.scala#L316-L332

as it means that handleUnidentifiedIndirectCall cannot cleanly return an ArrayBuffer of newly created Blocks which are then added to a Procedure and possibly queued in the current iterator. Instead, all this functionality has to be jumbled up - handleUnidentifiedIndirectCall has to then add the Blocks to the Procedure itself but it still has to either return the newly created Blocks separately or queue them itself too. Either approach is messier than what we currently have.

Additionally, are we even going to want to reassign a returnTarget, as this was not previously allowed? This does not seem too likely in the first place - I can only really see the case where a returnTarget is removed completely because the call has been identified as non-returning?

l-kent commented 3 months ago

fixed in #208