[all-commits] [llvm/llvm-project] fee168: [clang] Refactor `LangOptions` to specify compatib...

[Jan Svoboda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fee168913c752b1048a2fd48b27c698094462d52
      https://github.com/llvm/llvm-project/commit/fee168913c752b1048a2fd48b27c698094462d52
  Author: Jan Svoboda <jan_svoboda at apple.com>
  Date:   2025-07-07 (Mon, 07 Jul 2025)

  Changed paths:
    M clang/include/clang/Basic/LangOptions.def
    M clang/include/clang/Basic/LangOptions.h
    M clang/lib/Basic/LangOptions.cpp
    M clang/lib/Frontend/CompilerInvocation.cpp
    M clang/lib/Frontend/FrontendActions.cpp
    M clang/lib/Serialization/ASTReader.cpp
    M clang/lib/Serialization/ASTWriter.cpp

  Log Message:
  -----------
  [clang] Refactor `LangOptions` to specify compatibility as X macro arg (#146766)

This removes the `{BENIGN,COMPATIBLE}{,_ENUM,_VALUE}_LANGOPT` X macros
controlling `LangOptions`. These are permutations of the base `LANGOPT`,
`ENUM_LANGOPT` and `VALUE_LANGOPT` X macros that also carry the
information of their effect on AST (and therefore module compatibility).
Their functionality is now implemented by passing `Benign`, `Compatible`
or `NotCompatible` argument to the base X macros and using C++17 `if
constexpr` in the clients to achieve the same codegen.

This PR solves this FIXME:
```
// FIXME: Clients should be able to more easily select whether they want
// different levels of compatibility versus how to handle different kinds
// of option.
```

The base X macros are preserved, since they are used in `LangOptions.h`
to generate different kinds of field and function declarations for
flags, values and enums, which can't be achieved with `if constexpr`.

The new syntax also forces developers to think about compatibility when
adding new language option, hopefully reducing the number of new options
that are affecting by default even though they are benign or compatible.

Note that the `BENIGN_` macros used to forward to their `COMPATIBLE_`
counterparts. I don't think this ever kicked in, since there are no
clients of the `.def` file that define `COMPATIBLE_` without also
defining `BENIGN_`. However, this might be something downstream forks
need to take care of by doing `if constexpr (CK::Compatibility ==
CK::Benign || CK::Compatibility == CK::Compatible)` in place of `#define
COMPATIBLE_`.



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