Error generating Objective-C binding files

[brianquinlan]

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

[liamappelbe]

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.

[brianquinlan]

NSURLHandle is deprecated - is there a way to say that I don't care about any methods that use it?

[liamappelbe]

Method filtering is on the todo list: #251. I'll try to land it in the next version

[liamappelbe]

Oops, forgot to use a UniqueNamer for the function names. There's two wrapListenerBlock_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.

[brianquinlan]

I'm going to be out for 3 weeks soon so no hurry from my POV.

[dcharkes]

Oops, forgot to use a UniqueNamer for the function names. There's two wrapListenerBlock_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.

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.)

[liamappelbe]

The UniqueNamer part of this issue was fixed in #1339. For the other part of the issue, I'll investigate automatically ignoring deprecated APIs (#1338), and also implement method filtering (#251). These two fixes will be the focus of ffigen 14.0.0