Default repr(C) enums to c_int size

[workingjubilee]

This is what ISO C strongly implies this is correct, and
many processor-specific ABIs imply or mandate this size, so
"everyone" (LLVM, gcc...) defaults to emitting enums this way.
However, this is by no means guaranteed by ISO C,
and the bare-metal Arm targets show it can be overridden,
which rustc supports via c-enum-min-bits in a target.json.

The override is a flag named -fshort-enums in clang and gcc,
but introducing a CLI flag is probably unnecessary for rustc.
This flag can be used by non-Arm microcontroller targets,
like AVR and MSP430, but it is not enabled for them by default.
Rust programmers who know the size of a target's enums
can use explicit reprs, which also lets them match C23 code.

This change is most relevant to 16-bit targets: AVR and MSP430.
Most of rustc's targets use 32-bit ints, but ILP64 does exist.
Regardless, rustc should now correctly handle enums for
both very small and very large targets.

Thanks to William for confirming MSP430 behavior,
and to Waffle for better style and no-core size_of asserts.

Fixes #107361
Fixes #77806

[rustbot]

r? @lcnr

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

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[lcnr]

r? compiler

[workingjubilee]

cc @Rahix re: vibe-checking this AVR-related PR since it will affect the pile of target-spec.jsons that you maintain in avr-hal.

[Rahix]

Change looks reasonable to me. Re. target-specs, we derive ours from the upstream one using a small python script. I'll just re-synchronize once we update to a more recent nightly. But for now we are still blocked on #106619, anyway...

[jackh726]

Sorry, not my area of expertise...

r? compiler

[cjgillot]

I don't know anything about AVR either. @workingjubilee do you have somebody in mind for the review?
@jonas-schievink I saw you approved #76364, can you help?

[workingjubilee]

Jonas is an alumnus (and thank you).

I believe for one reason or another a lot of the people who are very active contributors regarding these targets (e.g. @dylanmckay, @cr1901, @Patryk27) are usually not formal Rust team members and of those who are more active with the Embedded WG they don't necessarily have a ton of active review cycles. Which is why I just tagged in Rahix.

[WaffleLapkin]

I'm not entirely sure what are the implications here, but from what I could find this seems like a correct solution.

I think this will be good to go after a couple of nitpicks and doc fixes.

r? @WaffleLapkin

[cr1901]

people who are very active contributors regarding these targets... are usually not formal Rust team members

I'm not aware of the process of becoming a formal team member for maintaining msp430. I just open bug reports and bisect when I notice the compiler pessimizes or otherwise breaks msp430 codegen. I also have little bandwidth to fix LLVM errors at present. Is this enough to be considered a maintainer if I add target-specific documentation?

Anyways, this PR looks fine to me. The below sample code compiles on msp430-elf-gcc (will test clang once I get past my build scripts getting a bit stale, but I can't imagine that the behavior would differ...)

Makefile

include include.mk

all: enum.elf

elf-info: enum.elf
        msp430-elf-objdump -D enum.elf > enum.lst
        msp430-elf-readelf -a --wide enum.elf > enum.sym
        msp430-elf-size -A enum.elf

enum.S: enum.c
        $(CC) -c $(CFLAGS) -S -o enum.S -I$(MSPINC) enum.c

enum.o: enum.S
        $(CC) -c $(CFLAGS) -o enum.o -I$(MSPINC) enum.S

enum.elf: enum.o
        $(CC) $(LDFLAGS) -o enum.elf -L$(MSPINC) enum.o

prog: enum.elf
        mspdebug $(MSPDRV) "prog enum.elf"

clean:
        rm -rf enum.elf enum.o enum.lst enum.sym enum.S

include.mk.sample

MSPINC=/path/to/include # https://github.com/pftbest/msp430_svd
MSPMCU=msp430g2211 # Define to desired micro to build on.
MSPDRV=rf2500 # tilib, etc. Input to mspdebug.

# GCC invocation
CC=msp430-elf-gcc
CFLAGS=-Os -mmcu=$(MSPMCU)
LDFLAGS=-mcpu=msp430 -Wl,-T$(MSPMCU).ld # Work around possible driver bug with -mcpu=msp430.
# -mmcu=$(MSPMCU) also works in place of both these options.

# Clang invocation- requires existing GCC.
# GCC_TOOLCHAIN=/path/to/gcc/toolchain # This can't be automated if not installing clang.
# CC=clang --target=msp430 --gcc-toolchain=$(GCC_TOOLCHAIN) # Or /path/to/clang if using clang's build directory.
# CFLAGS=-Os -mmcu=$(MSPMCU)
# LDFLAGS=-Wl,-T$(MSPMCU).ld # No such option -mcpu=msp430.
# -mmcu=$(MSPMCU) also works in place of providing a linker script.

enum.c

#include <assert.h>

enum foo
{
    BAR
};


int main(void)
{
    static_assert(sizeof(enum foo) == 2);
}

[workingjubilee]

• Fixup c_enum_min_bits to always work like that, not just when pulled from a target.json

[WaffleLapkin]

A couple of tiny nits and I think this is good to go, r=me when ready.

[workingjubilee]

@bors r=WaffleLapkin

[bors]

📌 Commit 2edf6c8 has been approved by WaffleLapkin

It is now in the queue for this repository.