[lldb-dev] swig generation

[Zachary Turner via lldb-dev]

On Fri, Nov 13, 2015 at 10:24 AM Todd Fiala <todd.fiala at gmail.com> wrote:

> On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner <zturner at google.com>
> wrote:
>
>> On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
>> lldb-dev at lists.llvm.org> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to do a few things with our swig generation and handling:
>>>
>>> * Create a maintainer-mode style setup where the swig Python bindings
>>> are generated and checked into the repo (I'll call it the static python
>>> binding).
>>>
>>> This will be used by default, removing the need for most people and all
>>> builders/bots from having swig on their system just for lldb.  In the event
>>> that Windows needs a different version (e.g. for, say, Python 3.5 support
>>> that is incompatible with the swig-1.3.40-generated bindings), we can
>>> support multiple source bindings, or we can post process the swig-1.3.x
>>> generated bindings.  We'll keep them by swig-{swig-major}-{swig-minor}.
>>> Internally over at Apple, we will stick with the swig-1.x bindings.  I
>>> don't think we will care about the dot release (1.3.40 vs. 1.3.39, for
>>> example).  We'll just make sure to use the latest for a
>>> {swig-major}.{swig-minor}.  As always, SB API changes generated by swig
>>> need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of
>>> generating usable Python wrappers).
>>>
>> I know you said you plan to stay on 1.x, but in this world of having SWIG
>> bindings checked in, does that open the door to potentially moving beyond
>> SWIG 1.x for the upstream?  I feel like the SWIG 1.x requirement holds the
>> upstream back, because there are a lot of hacks to workaround bugs and
>> limitations in SWIG, and it only understands the absolute most basic C /
>> C++ language constructs.  So we end up being limited in how we can design
>> SB APIs, all for reasons that having nothing to do with the upstream
>> project requirements, which is kind of a bummer.  It seems like there could
>> be a path here for the upstream to move forward, and anyone who is forced
>> to stay on an earlier version of SWIG could maintain whatever changes are
>> necessary to make this possible in a local repository.
>>
>>
> I may leave Greg to discuss that aspect (w/r/t using newer features).  The
> SB API itself is intended to be a very bare-bones linkage environment that
> does not break linkage requirements in ways that typical C++ binary
> libraries do (i.e. it does not use virtuals and follows a number of rules
> about data members so that it remains binary compatible across
> compiler/linker changes).
>

There's a couple of examples that come to mind.  C++11 is completely out,
for example.  In general this isn't a huge deal.  Nobody's going to be
passing rvalue references through the SB API or anything.  But even simple
things like enum classes are out.  1.x also doesn't support specifying the
underlying type of an enum, because it can't parse it.  In other words,
SWIG won't accept this:

enum Foo : unsigned {
};

This is actually important in MSVC because its algorithm for choosing the
underlying type and size of the enum differs from other compilers.  We've
got hundreds of warnings silenced in CMake because of this, and there's no
solution except upgrade SWIG.

We're also forced to use the archaic "const char* str, int len" syntax for
every single string, when we could be passing std strings or llvm
StringRefs.

No nested classes, namespace support doesn't work, and also missing out on
a ton of bugfixes and performance improvements of generated code.  Many
languages like Go aren't supported in 1.x, etc.  If I check the release
notes I could probably come up with more examples.

I don't mean to say that we have to do this with haste or anything, but I
think at some point there should probably be a path off of 1.x for the
upstream
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151113/0657e7dc/attachment.html>