Skip to content

Conversation

@tokyovigilante
Copy link

@tokyovigilante tokyovigilante commented Oct 3, 2025

Futhark crashes when parsing C headers containing LLVM block pointer types, identified when attempting to wrap Apple's libdispatch library.

https://github.com/swiftlang/swift-corelibs-libdispatch/blob/main/src/BlocksRuntime/Block.h

// dispatch/object.h (simplified)
typedef void (^dispatch_block_t)(void);

Attempting to parse with Futhark:

import futhark

importc:
  compilerArg "-D__BLOCKS__"
  compilerArg "-fblocks"
  sysPath "/usr/include"
  "dispatch/dispatch.h"

gives the error:

Error: unhandled exception: Field 'base' not found in JsonNode [KeyError]

Opir output for the above:

{
  "kind": "pointer",
  "depth": 1
}

Absent base key (appropriately) but then later unconditionally accesses json["base"] cause crashes.

findAlias() (Line 265): Crashes extracting type aliases
addUsings() (Line 311): Crashes tracking dependencies
toNimType() (Lines 346, 370, 382, 408): Crashes generating type definitions

Patch adds hasKey("base") guards before accessing json["base"] in all relevant locations:

findAlias(): Return empty string (no alias to track)
addUsings(): Skip dependency tracking (bare pointers have no dependencies)
toNimType(): Generate opaque pointer type

Disclosure: patch partially generated by Claude Code, but thoroughly manually tested and reviewed.

Fixes KeyError crash when Opir outputs pointer types without "base" key.

Problem:
Futhark unconditionally accessed json["base"] without checking existence, causing crashes on bare pointer types from certain C headers.

Fix:
Add hasKey("base") guards where required before accessing json["base"].
Generate opaque `pointer` type when base is missing.
@PMunch
Copy link
Owner

PMunch commented Oct 6, 2025

Hmm, this is very strange. Futhark definitely should support void pointers. Not quite sure what the caret notation in your snippet is though, is that even valid C?

@tokyovigilante
Copy link
Author

tokyovigilante commented Oct 6, 2025

Not quite sure what the caret notation in your snippet is though, is that even valid C?

Strictly speaking no, it's an LLVM C extension for blocks, which underpins Objective-C blocks as used in libdispatch. Sorry I've realised the description above isn't clear.

https://clang.llvm.org/docs/BlockLanguageSpec.html

Acknowledge this is not Futhark's issue, but hopefully the patch is additive only and doesn't break any other codegen. Haven't seen any issues with any of the other C libraries I'm using.

@tokyovigilante
Copy link
Author

Just as an update, I'm no longer using libdispatch as the interoperability with non-Swift languages on Linux isn't great (can't guarantee main queue executes on main thread primarily) which is disappointing given that the performance was very good in non-UI tasks. So I'm happy if you want to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants