+/* When the bimap isn't completely sufficient for handling the ANYOF node,
+ * flags (in node->flags of the ANYOF node) get set to indicate this. These
+ * are perennially in short supply. Beyond several cases where warnings need
+ * to be raised under certain circumstances, currently, there are six cases
+ * where the bitmap alone isn't sufficient. We could use six flags to
+ * represent the 6 cases, but to save flags bits, we play some games. The
+ * cases are:
+ *
+ * 1) The bitmap has a compiled-in very finite size. So something else needs
+ * to be used to specify if a code point that is too large for the bitmap
+ * actually matches. The mechanism currently is a swash or inversion
+ * list. ANYOF_ONLY_HAS_BITMAP, described above, being TRUE indicates
+ * there are no matches of too-large code points. But if it is FALSE,
+ * then almost certainly there are matches too large for the bitmap. (The
+ * other cases, described below, either imply this one or are extremely
+ * rare in practice.) So we can just assume that a too-large code point
+ * will need something beyond the bitmap if ANYOF_ONLY_HAS_BITMAP is
+ * FALSE, instead of having a separate flag for this.
+ * 2) A subset of item 1) is if all possible code points outside the bitmap
+ * match. This is a common occurrence when the class is complemented,
+ * like /[^ij]/. Therefore a bit is reserved to indicate this,
+ * rather than having an expensive swash created,
+ * ANYOF_MATCHES_ALL_ABOVE_BITMAP.
+ * 3) Under /d rules, it can happen that code points that are in the upper
+ * latin1 range (\x80-\xFF or their equivalents on EBCDIC platforms) match
+ * only if the runtime target string being matched against is UTF-8. For
+ * example /[\w[:punct:]]/d. This happens only for posix classes (with a
+ * couple of exceptions, like \d where it doesn't happen), and all such
+ * ones also have above-bitmap matches. Thus, 3) implies 1) as well.
+ * Note that /d rules are no longer encouraged; 'use 5.14' or higher
+ * deselects them. But a flag is required so that they can be properly
+ * handled. But it can be a shared flag: see 5) below.
+ * 4) Also under /d rules, something like /[\Wfoo]/ will match everything in
+ * the \x80-\xFF range, unless the string being matched against is UTF-8.
+ * A swash could be created for this case, but this is relatively common,
+ * and it turns out that it's all or nothing: if any one of these code
+ * points matches, they all do. Hence a single bit suffices. We use a
+ * shared flag that doesn't take up space by itself:
+ * ANYOF_SHARED_d_MATCHES_ALL_NON_UTF8_NON_ASCII_non_d_WARN_SUPER.
+ * This also implies 1), with one exception: [:^cntrl:].
+ * 5) A user-defined \p{} property may not have been defined by the time the
+ * regex is compiled. In this case, we don't know until runtime what it
+ * will match, so we have to assume it could match anything, including
+ * code points that ordinarily would be in the bitmap. A flag bit is
+ * necessary to indicate this , though it can be shared with the item 3)
+ * flag, as that only occurs under /d, and this only occurs under non-d.
+ * This case is quite uncommon in the field, and the /(?[ ...])/ construct
+ * is a better way to accomplish what this feature does. This case also
+ * implies 1).
+ * ANYOF_SHARED_d_UPPER_LATIN1_UTF8_STRING_MATCHES_non_d_RUNTIME_USER_PROP
+ * is the shared flag.
+ * 6) /[foo]/il may have folds that are only valid if the runtime locale is a
+ * UTF-8 one. These are quite rare, so it would be good to avoid the
+ * expense of looking for them. But /l matching is slow anyway, and we've
+ * traditionally not worried too much about its performance. And this
+ * condition requires the ANYOFL_FOLD flag to be set, so testing for
+ * that flag would be sufficient to rule out most cases of this. So it is
+ * unclear if this should have a flag or not. But, this flag can be
+ * shared with another, so it doesn't occupy extra space.
+ *
+ * At the moment, there is one spare bit, but this could be increased by
+ * various tricks.
+ *
+ * If just one more bit is needed, at this writing it seems to khw that the
+ * best choice would be to make ANYOF_MATCHES_ALL_ABOVE_BITMAP not a flag, but
+ * something like
+ *
+ * #define ANYOF_MATCHES_ALL_ABOVE_BITMAP ((U32) -2)