[ffigen] Add config ignore-source-errors

[mannprerak2]

Closes #439

• Added config ignore-source-errors and flag --ignore-source-errors to prevent generation of errors.
• Updated version, changelog, readme

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[mannprerak2]

@dcharkes this should be ready for review.

Regarding the failing windows test, since we are calling exit() it causes the entire test suite to be killed. It's probably some header error in one of the tests, but I'm not sure which.

I can run the tests twice and add some logs to figure out which test will fail. But to avoid these situations, is there any sort of work around for this? Can we maybe replace the calls to exit() with something else?

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:ffigen	11.0.0	ready to publish	ffigen-v11.0.0
package:native_toolchain_c	0.3.2	already published at pub.dev
package:jni	0.8.0-wip	WIP (no publish necessary)
package:native_assets_cli	0.3.2	already published at pub.dev
package:jnigen	0.8.0-wip	WIP (no publish necessary)
package:native_assets_builder	0.3.0	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[coveralls]

coverage: 91.746% (-6.4%) from 98.152%
when pulling 3aa6561 on mannprerak2:ffigen_severe_compiler_logs
into 5dca10e on dart-lang:main.

[dcharkes]

Thanks @mannprerak2!

[dcharkes]

What kind of warnings result in wrong generated code? Should we refuse to generate on all warnings?
If we refuse to generate for too many warnings, people might just start using ignore-source-errors instead of fixing the issues.

[mannprerak2]

True, for now I've only handled warnings/errors from libclang. (Excluding ObjC for now)

But I think anything which can potentially generate invalid bindings, that might silently break at runtime should be covered.

[dcharkes]

Should we mention -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/?

@liamappelbe what are typical errors we see with Objective-C?

[auto-submit]

auto label is removed for dart-lang/native/810, due to This PR has not met approval requirements for merging. You are not a member of dart-team and need 1 more review(s) in order to merge this PR.

• Merge guidelines: You need at least one approved review if you are already part of flutter-hackers or two member reviews if you are not a flutter-hacker before re-applying the autosubmit label. Reviewers: If you left a comment approving, please use the "approve" review action instead.