I'd add this assert block either at the very top or very bottom of the macro instead of in the middle of the operators.

There's no need to have a trailing \n character in your message. Clang literally writes out \n in the output and MSVC quotes the string, so you get a line with just an ending quote for it.

I think we'd actually want to disallow 0 right? Would a 0 ever be useable?

Oof... is there a separate patch for this duplicate value?? Seems wrong / would at least deserve a comment if nothing else.

This 7 probably depends on the answer to the above.

0 results in a bitmask that is 1 for all bits. It might not be useful, but at least it does not leave holes in the bitmask, so it is not as bad as other non-power-of-twos.

The assert cannot prevent the programmer from putting the wrong power of two. It only prevents values that result in bitmasks holes or more than one switch over point from zeros to ones.

That said, an explicit check for _max_enum_value not equals 0 could be added.

Would have to ask @Brecht Van Lommel (brecht). The change was made to prevent a warning message for unknown GPU: rB62419975b78b
Maybe it is just a temporary fix until the Metal work is further along. It could use a comment though.

I set the value to (1 << 7) is to ensure that GPU_DEVICE_ANY (AKA 0xff) is fully included in the bitmask. Since there is no (1 << 6) or (1 << 7), I think 7 is independent of the answer to the above comment.

Thanks, I committed a fix for that in rBaa1ae1d3c8ef: Fix overlapping GPU device bitmasks.