Can we call this something more descriptive and also store it in a way that's more conducive to examination than a raw int?

Or at least, if we store it as a raw int---which we'll need to pass into codegen later---print it out more nicely as OR-ed flags?

Can we call this something more descriptive

I want this to be consistent with whatever name insns.def uses (currently opt). Since we have to compare the interpreter implementation and the ZJIT implementation for checking compatibility, it'd be harder to maintain if the names have inconsistency.

If you need a description, we should add a comment. If you do need a rename of the variable, please rename that in insns.def first.

Sure, fair.

I want this to be consistent with whatever name insns.def uses

That's the rule I've been following for naming things too. 👍🏻

print it out more nicely as OR-ed flags?

I added some fancier printing (I wasn't printing the options at all before), plus a comment about what opt is. Does that seem sufficient?

I think there are a bunch more of these like ONIG_OPTION_DONT_CAPTURE_GROUP. Maybe something like this?

/// make a pair of stringified and int
macro_rules! strenum {
    ($name:ident) => {
        (stringify!($name), $name)
    };
}

static ALL_FLAGS: &[(&str, u32)] = &[
    strenum!(ONIG_OPTION_NONE),
    strenum!(ONIG_OPTION_IGNORECASE),
    strenum!(ONIG_OPTION_EXTEND),
    strenum!(ONIG_OPTION_MULTILINE),
    strenum!(ONIG_OPTION_SINGLELINE),
    strenum!(ONIG_OPTION_FIND_LONGEST),
];

/// iterate over ALL_FLAGS and call bitflag!
macro_rules! bitflags {
    ($writer:expr, $flag:expr) => {
        let mut sep = "";
        for (name, flag) in ALL_FLAGS {
            if $flag & flag != 0 {
                write!($writer, "{sep}{name}")?;
                sep = "|";
            }
        }
    };
}

impl std::fmt::Display for F {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        bitflags!(f, self.options);
        Ok(())
    }
}

Please pardon the Rust---I'm very much not an expert

Actually this is cleaner I think

macro_rules! bitflags {
    ($writer:expr, $bitfield:expr, $($flag:ident),*) => {
        let mut sep = "";
        $(
            if $bitfield & $flag != 0 {
                write!($writer, "{sep}{}", stringify!($flag))?;
                sep = "|";
            }
        )*
    };
}

impl std::fmt::Display for F {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        bitflags!(f, self.options, ONIG_OPTION_NONE, ONIG_OPTION_IGNORECASE, ONIG_OPTION_EXTEND, ONIG_OPTION_MULTILINE, ONIG_OPTION_SINGLELINE, ONIG_OPTION_FIND_LONGEST);
        Ok(())
    }
}

(but please get all the relevant flags from include/ruby/onigmo.h)

Hm, I don't think all of those onigmo flags match exactly what is in opt here. I modeled this printing after

So 16 is ARG_ENCODING_FIXED and 32 is ARG_NO_ENCODING. Those don't match up with the ognimo options with the same values. NOENCODING with the n flag, for example:

% ruby --dump=insn -e '/#{}/n'
== disasm: #<ISeq:<main>@-e:1 (1,0)-(1,6)>
0000 putobject                              ""                        (   1)[Li]
0002 putnil
0003 dup
0004 objtostring                            <calldata!mid:to_s, argc:0, FCALL|ARGS_SIMPLE>
0006 anytostring
0007 toregexp                               32, 2
0010 leave

% ruby -e 'p Regexp::NOENCODING; p //n.options'
32
32

ARG_NO_ENCODING is easy enough to display as n. I'm not sure how best to print ARG_ENCODING_FIXED though since it seems like the option itself doesn't tell us whether it's an e, s, or u.

.......huh. That's a weird subset. I don't think we need to print as one-char; printing as OR-ed long-name is probably fine (like the function call flags). Thank you for investigating. I trust your judgement here

I'll try printing it as the Ruby constant name like IGNORECASE|EXTENDED|MULTILINE|FIXEDENCODING|NOENCODING

OK, I've got something that works and I think covers all the possible options. I didn't end up using the macros you offered above since using the Ruby constant name made them somewhat less useful, but I'm open to suggestions if there's a more elegant way to do this.