native
native copied to clipboard
dart-lang
Error generating Objective-C binding files
As of cd8eddf8ad5b953127acf884f2b8a614482a8b0f, this objective-c binding code is generated and contains these compilation errors:
Semantic Issue (Xcode): Redefinition of 'wrapListenerBlock_ObjCBlock_ffiVoid_NSArray'
/Users/bquinlan/dart/http/pkgs/cupertino_http/src/native_cupertino_bindings.m:102:15
Semantic Issue (Xcode): Unknown type name 'NSURLHandle'
/Users/bquinlan/dart/http/pkgs/cupertino_http/src/native_cupertino_bindings.m:434:42
Semantic Issue (Xcode): Unknown type name 'NSURLHandle'
/Users/bquinlan/dart/http/pkgs/cupertino_http/src/native_cupertino_bindings.m:436:48
Semantic Issue (Xcode): Unknown type name 'NSURLHandle'
/Users/bquinlan/dart/http/pkgs/cupertino_http/src/native_cupertino_bindings.m:443:42
Semantic Issue (Xcode): Unknown type name 'NSURLHandle'
/Users/bquinlan/dart/http/pkgs/cupertino_http/src/native_cupertino_bindings.m:445:48
Semantic Issue (Xcode): Unknown type name 'NSURLHandle'
/Users/bquinlan/dart/http/pkgs/cupertino_http/src/native_cupertino_bindings.m:452:42
Semantic Issue (Xcode): Unknown type name 'NSURLHandle'
/Users/bquinlan/dart/http/pkgs/cupertino_http/src/native_cupertino_bindings.m:454:48
Oops, forgot to use a UniqueNamer for the function names. There's two wrapListenerBlock_ObjCBlock_ffiVoid_NSArrays.
For the unknown type name error, I guess there's a missing import. You might be able to work around it by adding the header that declares NSURLHandle as an entry point. Otherwise I'll probably need to add a preamble option to the config, like we have for the Dart bindings.
Method filtering is on the todo list: https://github.com/dart-lang/native/issues/251. I'll try to land it in the next version
Oops, forgot to use a
UniqueNamerfor the function names. There's twowrapListenerBlock_ObjCBlock_ffiVoid_NSArrays.
Actually it's a bit more complicated than this. The function is being unique named (automatically, after addDependencies), but only its Dart name is being deduped. There's no facility to rename the C-side name (the originalName) in ffigen, since we've never had to do this before. There's no clean fix for this atm. I can hack something together or we can wait for the transformer refactor (#1259) for a clean fix.
Oops, forgot to use a
UniqueNamerfor the function names. There's twowrapListenerBlock_ObjCBlock_ffiVoid_NSArrays.Actually it's a bit more complicated than this. The function is being unique named (automatically, after
addDependencies), but only its Dart name is being deduped. There's no facility to rename the C-side name (theoriginalName) in ffigen, since we've never had to do this before. There's no clean fix for this atm. I can hack something together or we can wait for the transformer refactor (#1259) for a clean fix.
Ah yes that's a bug, so we either need to have an originalCName and renamedCName. Or make sure that the name deduplication takes into account both the Dart and C name conflicts. I think the first option makes more sense.
Implementing C name dedup before transformers is probably fine. We already have it for the Dart name, so it wont make the code that much more dirty. Esp. the code generation part using the renamed names will be the same changes with or without the transformers. Only the renaming part itself will differ with transformers. So it's probably fine to implement this before implementing the transformers. (But it's fine with me if this is postponed until we have transformers. Whatever you prefer.)
The UniqueNamer part of this issue was fixed in https://github.com/dart-lang/native/pull/1339. For the other part of the issue, I'll investigate automatically ignoring deprecated APIs (https://github.com/dart-lang/native/issues/1338), and also implement method filtering (https://github.com/dart-lang/native/issues/251). These two fixes will be the focus of ffigen 14.0.0