Fmt flags refactor

[richo]

While implementing the fmt::Pointer traits, needing to awkwardly bitshift the variants of an enum everywhere irked me as being very awkward. Considering these values are never passed as arguments, it's not like their membership in the enum actually grants any type safety.

bitflags is not available in core, so I manually created the bitflags. This shouldn't break existing code, since they're not exported, but it seems that they should be, since there doesn't appear to be a blessed way to test for, eg the alternate flag in a formatter in user code.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[richo]

Err, tbc this is WIP. I had a moment and opened the PR before running the tests, which I have undoubtedly broken. Open to feedback on the spirit of the PR though!

[alexcrichton]

Due to the unstable internals, this shouldn't need to bother with a V2 flag format. Additionally, I suspect that a change such as this would want to be accompanied with a stabilization of the flags function on Formatter as well, so this may wish to have some broader discussion before moving forward.

[richo]

That sounds reasonable (And definitely lines up with my experience once I started getting fmt_macros to work around this). Is the correct move forward an RFC or a thread on internals? I care about this enough to shepard it.

[alexcrichton]

A thread on internals is probably fine for now, I suspect that the two main options here would be specific is_foo accessors or just a packed bitflags as you've done here, so there's not a whole lot of design space, just want to make sure others are aware!

[richo]

Closing for now in favour of http://internals.rust-lang.org/t/stabilising-formatter-flags/1927