dart-lang/native

At the moment all our C++ integration tests manually set various compilerOptions related to C++. We should instead set some sensible defaults when the language is set to C++.

At the moment the config API gives you two options for passing args to clang, using Input.compilerOptions: Use the defaults, which work for 90% of cases Pass custom args, overwriting the defaults The default params depend on: the host OS the target language specified in the config probably other config elements in future (especially with C++ support in the works) some non-trivial logic that attempts to find system headers Often what users want is to add extra args to the defaults, not replace them. Users shouldn't have to replicate our complicated default arg logic. In my own configs, I often end up importing some of the internal utils that calculate the default args. Option 1: Expose utils The obvious solution would be to clean up and expose those internal utils. That's a bit fiddly because the args depend on elements from the config. There's no clean way of building that API, aside from asking the user to repeat themselves (eg specify the target language in both the config and th

Summary When ffigen skips a typedef whose name matches the struct/union it refers to (the usual opaque-handle idiom typedef struct Foo Foo;), the documentation comment attached to the typedef cursor is discarded. The compound declaration has no comment of its own, so the generated binding and any consumer of ffigen's AST see an undocumented type. Example /// Opaque scene handle; create with scene_new, free with scene_free. typedef struct GeometryScene GeometryScene; typedefdecl_parser.dart logs "Name matches with referred struct/union" and calls addUnsupportedTypealiasToSeen, but never transfers the typedef's doc comment to the referred compound. Expected behavior When a typedef is skipped for having the same name as its compound, hand getCursorDocComment (or equivalent) from the typedef cursor to the compound before the typedef is dropped. Actual behavior The struct/union is generated without documentation. bindsmith works around this with a local header scanner (header_docs.dart) and

We should ignore the version line when checking that the bindings are up to date. It's not very useful and very noisy on version bumps. It turns simple bug fix PRs into >100 file messes: #3586

We tell people to write a Dart config script for FFIgen/JNIgen, and give them a bunch of examples. But if you write a config, and the API elements you expect don't appear in your bindings, it's unclear what to do next. One debugging approach, under the new visitor API, is to write a custom visitor that just prints all the API elements. Then you can see if the problem is that you haven't set the correct entry points (headers etc), or your filters are misconfigured. We should provide a util that does this, so users don't have to do it. Best API is probably an extension method on FfiGenerator/JniGenerator that dumps all the AST nodes (public AST nodes, as seen by a custom visitor). Eg: Func(originalName, USR) ObjCInterface(originalName, USR) ObjCMethod(ObjCInterface(originalName, USR), methodSelector) ... That output is not the most human readable format, but it's clear and greppable. Other suggestions welcome.