[all-commits] [llvm/llvm-project] 0c332a: [clang-format] Preserve whitespace in selected macros

[JakeMerdichAMD via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 0c332a7784c649038bd237a60fa18b45a3dea90d
      https://github.com/llvm/llvm-project/commit/0c332a7784c649038bd237a60fa18b45a3dea90d
  Author: Jake Merdich <Jake.Merdich at amd.com>
  Date:   2020-06-29 (Mon, 29 Jun 2020)

  Changed paths:
    M clang/docs/ClangFormatStyleOptions.rst
    M clang/include/clang/Format/Format.h
    M clang/lib/Format/Format.cpp
    M clang/lib/Format/FormatToken.h
    M clang/lib/Format/FormatTokenLexer.cpp
    M clang/lib/Format/TokenAnnotator.cpp
    M clang/unittests/Format/FormatTest.cpp

  Log Message:
  -----------
  [clang-format] Preserve whitespace in selected macros

Summary:
https://bugs.llvm.org/show_bug.cgi?id=46383

When the c preprocessor stringizes tokens, the generated string literals
are affected by the whitespace. This means clang-format can affect
codegen silently, adding spaces and newlines to strings.  Practically
speaking, the vast majority of cases will be harmless, only affecting
single identifiers or debug macros.

In the interest of doing no harm in other cases though, this introduces
a blacklist option 'WhitespaceSensitiveMacros', which contains a list of
names of function-like macros whose contents should not be touched by
clang-format, period. Clang-format can't automatically detect these
without a real compile context, so users will have to specify it
explicitly (it still beats clang-format off'ing at every invocation).

Defaults include "STRINGIZE", "PP_STRINGIZE", and "BOOST_PP_STRINGIZE".

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D82620