[all-commits] [llvm/llvm-project] 28366b: [clang] [Sema] Widen enumerators that overflow a _...

[Luan Rabelo via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 28366bc273fb734027a10dad2a6245665ac138f6
      https://github.com/llvm/llvm-project/commit/28366bc273fb734027a10dad2a6245665ac138f6
  Author: Luan Rabelo <96793857+Lu4nScr1pt1ng at users.noreply.github.com>
  Date:   2026-07-13 (Mon, 13 Jul 2026)

  Changed paths:
    M clang/docs/ReleaseNotes.md
    M clang/lib/Sema/SemaDecl.cpp
    M clang/test/Sema/enum.c

  Log Message:
  -----------
  [clang] [Sema] Widen enumerators that overflow a _BitInt type (C23) (#208230)

When an enumerator has no explicit value and the previous enumerator has
a
_BitInt type whose maximum is reached, incrementing should widen to a
suitably sized standard integer type (C23 6.7.3.3p12 excludes
bit-precise
types from the widening). Clang instead kept the _BitInt type and let
the
value wrap around, with a misleading "not representable in the largest
integer type" warning.

The problem is in getNextLargerIntegralType: it compared candidate types
against the storage size of the previous type. A _BitInt(33) is stored
in
64 bits, so no standard type looked larger and the widening never
happened.
Comparing against the value width (getIntWidth) fixes it: the enumerator
now gets the next standard type that can hold the value, and the
behavior
matches GCC (verified against GCC 15.2).

For standard integer types getIntWidth equals getTypeSize, so this
changes
behavior only for bit-precise types.

The new tests in enum.c check the widened type and the value from inside
the enum definition, like the reproducer in the issue; they fail without
this change. Incrementing the max of a _BitInt(64) still warns, since no
standard type can hold that value, and that case is covered too.

Fixes #208163



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications