[Bug translator/16793] New: Exempt built-in tapsets from --compatible parsing changes

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16793

            Bug ID: 16793
           Summary: Exempt built-in tapsets from --compatible parsing
                    changes
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: jistone at redhat dot com
            Blocks: 13664

When we make a change to the parser that also keeps its old behavior with some
--compatible option, we've essentially made a tiny fork in the language.  That
puts our tapset code in a tight spot, where we must either stick to the least
common denominator of features, or alternate their syntax choice according to
systemtap_v conditionals.  (Tapsets already use systemtap_v for their own
compatibility changes, but they shouldn't need to do so outside that.)

This proposal is that built-in tapsets should always be parsed with the current
syntax, no matter what the user's --compatible option is.  This way tapsets can
freely make use of new features, like PR13664 types.  Tapsets will still see
the chosen systemtap_v for their own compatibility conditions though.

SYSTEMTAP_TAPSET should be treated the same as built-in tapsets for this
purpose, since it overrides the built-in.  However, -I paths should be parsed
under --compatible just as the primary user script is, so a user trying to run
an old collection of code can still do so.

If a third-party distro package installs files into the main tapset path, those
will have to be prepared for new syntax.  I don't think this is a problem,
because such files would have previously been at the whim of --compatible
anyway, so now they too will have a more stable base.

-- 
You are receiving this mail because:
You are the assignee for the bug.