Would it be possible to add an "opt-out" feature to the bitflags! macro that disables generating the core::fmt and/or FromStr impls on InternalBitFlags?

Obviously not final syntax, but I was thinking something along the lines of:

bitflags::bitflags! {
    !impl FromStr;
    !impl fmt;

    #[derive(Copy, Clone)]
    pub struct Flags: u32 {
        const A = 1;
        const B = 2;
        const C = 4;
        const D = 8;
    }
}

Thinking more broadly: it might be interesting to consider extending this idea to arbitrary subsets of the generated API (or even having having a complimentary bitflags_with! macro where you manually opt-in to various impls), but I thought I'd start by asking about the most pressing use-case first.

For context, I'm using bitflags! in a library designed to run in very resource constrained environments, where every single byte of code matters.

While updating to bitflags version 2, I noticed a (relatively) substantial binary size bump in my test binaries, and after digging into it, I narrowed things down to a "spooky action at a distance" interaction between the code in the generated FromStr impl, and some unrelated code elsewhere in the project. You can read the details over at daniel5151/gdbstub#138 (comment), but suffice it to say, I was quite surprised to see that seemingly "dead code" could still affect codegen like that.

Of course, this is something I can (and will) work-around on my end, but thought I might as well open the issue anyways.

I should note that this might not be as niche of an ask as you might think.

Many embedded Rust projects avoid core::fmt and core::str methods/machinery like the plague, as they can result in substantial binary bloat on resource constrained platforms. The popularity of projects like ufmt and defmt are due in no small part to the inefficiencies of the core lib in embedded contexts.

Given that bitflags is commonly used in these sorts of projects, it would be nice to have a opt-in way to squeeze every last ounce of performance from the generated code (without resorting to hand-rolling a custom bitflags macro).