PyKF5 typedef rules

[Shaheed Haque]

Hi Steve,

One of the issues I noticed during the rebasing to KDE/master is that
the format of the typedef rule database has changed. It used to
contain two regexp fields plus a function pointer and now it has two
additional regexp fields:

    0. A regular expression which matches the fully-qualified name of the
    "container" enclosing the typedef.

    1. A regular expression which matches the typedef name.

    2. A regular expression which matches the function result for a function
    pointer typedef.

    3. A regular expression which matches the typedef declaration (e.g.
    "typedef int foo").

    4. A function.

The new fields 2 and 3 clearly give access to parts of the definition
not previously easily visible to rule writers. I have used them in
cases like this to automatically generate the %MappedTypes for QMaps:

       [".*", ".*", ".*", "QMap<.*>", _typedef_qmap_typecode],

Since, by definition, none of your rules databases presently contain
the two extra fields, I could achieve backwards compatibility by
automatically adding the two extra columns when I see only three are
present (at rule compilation time). I'm not sure if I see any
alternative way forward but perhaps you can?

There is a similar case for the function rule database which I hinted
at before, detailed here. The current database does not have anywhere
to store/match and prefix/suffix keywords around a function like
"static" and "const". As an example, in KDesktopFile, you presently
get rid of one of a pair of duplicate functions (from SIP's point of
view) by getting rid of the one wit the const prefix like this:

        ["KDesktopFile", ".*", ".*", "const KConfigGroup", ".*",
rules_engine.function_discard],

while I get rid of the non-const one by having the handler function
deep-dive into the function cursor to look for the const suffix...or
rather, since I added the prefix/suffix to the sip dictionary, the
handler simply does this:

    if "const" not in sip["suffix"]:
        rules_engine.function_discard(container, function, sip, matcher)

This has the slight downside in that the automatic change-detection
logic (which prints the "Modified by..." stuff) does not know there is
a change. Now, to make mactching on prefix or suffix easier, just as
proposed above for the typedef rule database, it would be possible for
me to add two extra fields to the structure, defaulting them for now.
I have tended towards NOT making this change, but would welcome your
input. (Part of me thinks that if we are doing the typedef change
anyway, then...).

One additional option would be to only keep the default logic in place
temporarily; once you have migrated all your rule sets to the new
format(s), we could remove the defaulting, as this will likely make
future changes easier to handle.

Please let me know what you think for both the typedef and function rule cases.

Thanks, Shaheed