[Bug]: IR generation crashes on ERC7739-style calldata tuple destructuring ('NoneType' object has no attribute 'parameters'), silently dropping inheriting contracts from analysis

[oladoteth]

What happened

Slither fails to build IR for Uniswap Calibur's ERC7739._isValidTypedDataSig, which destructures a calldata tuple returned by OpenZeppelin's draft-ERC7739Utils through using ERC7739Utils for *. The parse error is:

'NoneType' object has no attribute 'parameters'

The damaging part is the failure mode: every contract that inherits Calibur is then dropped from analysis entirely, while the run still completes and reports zero findings for them. We proved the silent drop by injecting an arbitrary low-level call into a subclass: zero findings; the identical injection in a non-inheriting contract was flagged immediately.

Reproduction

git clone --recurse-submodules https://github.com/Uniswap/calibur
cd calibur
slither .

Or, for the silent-drop demonstration specifically: our repo keeps a canary test that plants a known vulnerability in a Calibur-inheriting fixture and asserts Slither misses it: https://github.com/xanderslabs/avok.js/blob/main/contracts/test/SlitherCanary.t.sol

Note via_ir cannot be disabled as a workaround: Calibur does not compile without it (stack too deep).

Versions

Reproduced on Slither 0.11.5 and 0.11.6 (latest at time of filing), Python via pipx, solc 0.8.29, macOS. (Aderyn 0.6.8 also panics on the same project, for what it's worth.)

Impact

Calibur is an audited, deployed EIP-7702 delegate that projects are encouraged to subclass; any such subclass currently gets a clean Slither run that has analyzed nothing. A hard error on IR failure (or a per-contract 'not analyzed' report) would make this failure loud instead of silent.

[DefiAudit0x]

I reproduced this on the current master baseline (eef5df9) with Slither 0.11.6 and Foundry v1.7.1 using the Calibur reproduction described above. Slither logs Impossible to generate IR ... 'NoneType' object has no attribute 'parameters' for both Calibur._isValidTypedDataSig and CaliburEntry._isValidTypedDataSig, but the command completes and reports 121 contracts analyzed. The affected contracts therefore do not appear to fail the overall analysis.

Before implementing a fix, would you prefer (1) making this IR-generation failure fatal by default, or (2) preserving the run while emitting an explicit per-contract not analyzed result? I have not modified any code yet and would be happy to prepare a focused regression test once the preferred behavior is confirmed.

[DefiAudit0x]

Found the actual root cause while preparing a fix: it is not specific to tuple destructuring - any contract whose ancestors attach libraries to the same type collides in the inherited using-for map.

Contract.analyze_using_for() merged the directives inherited from each father with dict.update(), so when two ancestors declare using X for * only the last one survives. Calibur inherits using EntrypointLib for *; (ERC4337Account) and using ERC7739Utils for *; (ERC7739) — the latter was dropped, wrappedSignature.decodeTypedDataSig() stayed an unresolved HighLevelCall, and convert_constant_types() then crashed on None.parameters, silently discarding _isValidTypedDataSig (and everything inheriting it) from the analysis.

PR #3094 merges the inherited directives with merge_using_for() (the helper already used for top-level directives) so they accumulate. On calibur@main the two Impossible to generate IR errors are gone and all 121 contracts are fully analyzed, and a new regression test covers the minimal two-father case.

That also makes my earlier question above mostly moot for this pattern: with the directive merged, the crash no longer happens at all. Whether other unresolvable calls should become fatal instead of silent remains a valid design question, but it now looks orthogonal to this issue.