V0.7.0 new traces

[qiweiii]

minor fixes, and leave the rest since not easy to find source of mismatch, can revisit later, and maybe some can be fix during 0.7.1 traces

[codecov]

Codecov Report

❌ Patch coverage is 98.80952% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.89%. Comparing base (07b8b47) to head (328986f).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
.../Blockchain/VMInvocations/HostCall/HostCalls.swift	87.50%	1 Missing ⚠️
PolkaVM/Sources/PolkaVM/Engine.swift	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #369      +/-   ##
==========================================
+ Coverage   81.73%   81.89%   +0.15%     
==========================================
  Files         381      381              
  Lines       33912    34012     +100     
==========================================
+ Hits        27719    27854     +135     
+ Misses       6193     6158      -35     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Found several issues including leftover debug logs, a potential crash from a removed nil check, an unsafe force-unwrap in a test, and a confusing comment change. The remaining changes are bug fixes or acceptable refactoring.

---

Suggestions that couldn't be attached to a specific line

Blockchain/Sources/Blockchain/RuntimeProtocols/Accumulation.swift:649, 662

The file contains debug logging statements that should be removed before merging.

---

Blockchain/Sources/Blockchain/VMInvocations/HostCall/HostCalls.swift:297, 316

The file contains debug logging statements that should be removed before merging.

[github-actions]

Found potential correctness and robustness issues in memory initialization, instruction name parsing, a test using force-unwrapping without bounds checks, and a writable-check regression for nil values with non-zero length.

---

Suggestions that couldn't be attached to a specific line

PolkaVM/Sources/PolkaVM/Memory/StandardMemory.swift:59

heapZone data is now set directly to readWriteData without extending/zero-filling to cover heapEmptyPagesSize. This can cause out-of-bounds or undefined reads/writes for the uninitialized heap region since Zone's backing data may be shorter than endAddress - startAddress. Actionable fix: reintroduce zero-extension to the full heap zone size before assigning. For example:

var heapData = readWriteData
let totalHeapSize = Int(heapDataPagesLen + heapEmptyPagesSize)
if heapData.count < totalHeapSize {
let oldSize = heapData.count
heapData.count = totalHeapSize
heapData.withUnsafeMutableBytes { bytes in
memset(bytes.baseAddress!.advanced(by: oldSize), 0, totalHeapSize - oldSize)
}
}
heapZone = Zone(startAddress: heapStart, endAddress: heapStart + heapDataPagesLen + heapEmptyPagesSize, data: heapData)

---

PolkaVM/Sources/PolkaVM/Memory/StandardMemory.swift:65

stackZone data is now initialized to an empty Data(), whereas previously it was zero-filled to stackPageAlignedSize. Any reads from the stack zone can panic or return invalid data due to missing backing storage. Actionable fix: restore zero-initialization to the stack zone size:

let stackData = Data(count: Int(stackPageAlignedSize))
stackZone = Zone(startAddress: stackStartAddr, endAddress: UInt32(config.pvmProgramInitStackBaseAddress), data: stackData)

---

PolkaVM/Sources/PolkaVM/Engine.swift:101

Instruction name cleanup now replaces "Instructions::" but no longer removes "Instructions.". If typeName uses dot notation (common in Swift), this will leave the module prefix intact and break the intended formatting. Actionable fix: handle both separators or strip the prefix more generically. For example:

let cleanName = typeName
.replacingOccurrences(of: "Instructions.", with: "")
.replacingOccurrences(of: "Instructions::", with: "")

[xlc]

this can never be true if totalSize is UInt32. we simply want to ensure the above any UInt32 is <= UInt32.max.
what we wanted is to ensure the above calculation can never overflow and handle the overflow error

[qiweiii]

totalSize is Int, and we want to check <= 2^32, but UInt32.max + 1 part will have overflow so moved it to the left

changed to totalSize <= 0x1_0000_0000 to be simpler