anonymouspc wrote:
> Can you elaborate on the motivation for this? What are some scenarios in
> which it's necessary or important for a user to distinguish between macros
> defined in source code and macros defined on the command-line?
Here are a few scenarios:
1. Users need to know whether a macro is fixed (defined as part of the source)
or configuration-dependent (supplied by the build).
- **source-defined** macros are typically part of an API contract or an
implementation technique. For example:
- `stdin`, `offsetof`
- `UINT8_MAX`
- `BOOST_FUSION_ADAPT_STRUCT`, `BOOST_PP_REPEAT`
They generally aren’t meant to be toggled per build.
- **command-line-defined** macros are commonly used to select between build
variants. For example:
- `DEBUG`, `NDEBUG`
- `PKG_STATIC`, `PKG_SHARED`,
- `_GLIBCXX_USE_CXX11_ABI`.
These can change depending on the compile command, CMake options,
toolchain, etc.
2. Editors/IDEs may want to visually de-emphasize code that is never reachable
under the current configuration, but should be careful **not to mislead the
user**. For example,
- code guarded by `#if __cpp_concepts`, `#if __cpp_lib_ranges` can be safely
dimmed in `-std=c++17`.
- code guarded by `#if NDEBUG`, `#if TBB_SHARED` is dependent on command
line. They should not be treated as dead code in the same way.
-----
I’m adding an additional flag so that:
- Users who care about the distinction (like me) can quickly identify
command-line-defined vs source-defined macros.
- Users who don’t care can ignore it without changing their workflow.
https://github.com/llvm/llvm-project/pull/175495
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
