Unfortunately we've stopped using travis now, because travis stopped really usefully supporting FOSS projects. The Linux CI is now using github actions.

I've updated the CI to use GHA (only the Linux build as we no longer seem to have macos jobs - not sure if there's a good reason for that, but adding the first macos job is harder than just adding another Linux job).

Unfortunately the CFFI job failed - I haven't looked into why: https://github.com/swig/swig/runs/5442188613?check_suite_focus=true

Oh, I think it's that the env vars need setting for the build too.

OK, the cffi CI now passes!

@egao1980 What's left to do?

@egao1980 I managed to get the CI to pass - what's left to do here?

Even if we're not ready to promote CFFI to "supported" status, it would be good to merge the bulk of these updates if we're at the point where they should only be improving the situation.

Amazing @ojwb ! As far as I remember that was all I was asked to fix. So please go ahead with the pull request.

There is some reference to Lisp instead of CFFI in this patch. Can we make this consistent please, that is, use one or the other. So, I think this will just entail renaming Lisp.html to CFFI.html. Is there a case for adding in other Lisp variants to SWIG?

CFFI is a Lisp library that is one of the ways to interface to native libraries from Common Lisp. Similar to JNI /JNA in Java.

Congrats on getting the test-suite to run and for bringing this back to life. Hardly any tests seem to run on Github Actions though. It doesn't look like any C++ tests are being run.

The full requirements to be considered for experimental status are documented here: https://htmlpreview.github.io/?https://github.com/swig/swig/blob/master/Doc/Manual/Extending.html#Extending_language_status. I suggest you create a set of tick boxes from this in this pull request ticking the items you think that meet the experimental status and then I'll check/review.

A couple of standout problems are the required missing examples and I don't consider the documentation to be ready. Could you please spend a bit of time enhancing it. Python and Java are good reference chapters. I'd say that the guiding principle is to have lots of small easy to understand examples covering various C/C++ features. Documenting cffi typemaps and providing example usage of them is essential. The documentation on the various CFFI features does not read well to me, I don't understand it. I think they should be covered at a time with clear motivation and examples.

Thanks for the feedback. C++ tests are missing due to lack of C++ support:) everything else could be added later as this PR is just to restore CFFI that was removed from SWIG a year ago.

Looking at the experimental status requirements:

Will at least implement basic functionality - support wrapping C functions and simple C++ classes and templates.

Apparently no C++ support yet.

Have its own documentation chapter containing a reasonable level of detail.
The documentation must provide enough basic functionality for a user to get started.

This patch adds references to Lisp.html, but Lisp.html itself seems to be missing from the patch so I can't judge what it might contain. @egao1980 Did you write Lisp.html but fail to git add it?

Have fully functional examples of basic functionality (the simple and class examples).

There aren't any examples yet.

The test-suite must be implemented and include a few runtime tests for both C and C++ test cases.

There don't seem to be any _runme.lisp files (though there seems to be support for running them).

Failing tests must be put into one of the FAILING_CPP_TESTS or FAILING_C_TESTS lists in the test-suite.
This will ensure the test-suite can be superficially made to pass by ignoring failing tests.
The number of tests in these lists should be no greater than half of the number of tests in the full test-suite.

Testsuite as it stands passes, so this seems to be fully satisfied.

The examples and test-suite must also be fully functioning on the Github Actions Continuous Integration platform.
However, experimental languages will be flagged as 'continue-on-error'.
This means that pull requests and normal development commits will not break the entire Github Actions build should an experimental language fail.

The test-suite is fully functioning in CI. No examples currently, but if there were I think they'd also work in CI.

I originally said:

Even if we're not ready to promote CFFI to "supported" status, it would be good to merge the bulk of these updates if we're at the point where they should only be improving the situation.

I'd not considered when I wrote that that we can't actually enable CI for cffi until we are at the point of at least setting cffi to "experimental" status, so the benefits of merging most of this without any status change seem less clear to me and you'd need to rebuild a branch with the remaining changes if I merge part of it. @egao1980 Thoughts?

We're about to release swig-4.1.0 and as the criteria for reviving CFFI to experimental status has stalled, I have gone ahead with the complete removal of CFFI as the second and final stage of disabling a number of languages that began in swig-4.0.0, see #2009.

Anyone interested in reviving CFFI should revert cea25ab, then possibly apply the patch from this pull request as a starting point to meeting experimental status.

@egao1980 It looks like you failed to git add Doc/Manual/Lisp.html - do you have it locally still? Even if you don't plan to pick this PR up again, it'd be helpful to have all the file in case someone else wants to revive it.

Oh wait, I just realised that file existed before wsfulton removed the CFFI support in cea25ab, so if someone reverts that commit and then applies the changes here they will have Lisp.html (though it's presumably in need of updating).

Yep, I'll try to get back to this this month :)

Once #2990 is merged, cffi.cxx will need updating.

The rawval attribute is gone, and value will always be a valid C/C++ expression (so for a string or char literal it's suitably escaped and includes quotes).

It looks like cffi.cxx tries to convert constant values and emit them in the target language. For that case you probably want to use the new stringval attribute which is set for T_STRING, T_WSTRING, T_CHAR and T_WCHAR literal constants and contains the string's value as a byte sequence so you can escape it exactly as needed (unless the string and character escaping is identical to C). For character types, stringval should be a single byte.