Skip to content

Clang format breaks macro by removing new lines #42087

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
llvmbot opened this issue Jul 24, 2019 · 3 comments
Closed

Clang format breaks macro by removing new lines #42087

llvmbot opened this issue Jul 24, 2019 · 3 comments
Labels
bugzilla Issues migrated from bugzilla clang-format confirmed Verified by a second party invalid-code-generation Tool (e.g. clang-format) produced invalid code that no longer compiles

Comments

@llvmbot
Copy link
Member

llvmbot commented Jul 24, 2019

Bugzilla Link 42742
Version unspecified
OS Linux
Attachments Header and dot-Clang format config
Reporter LLVM Bugzilla Contributor

Extended Description

The following macros become inlined and so cannot be compiled:

#ifndef badmacrosh
#define badmarcosh

#define NS_FIRSTBAD_NAMESPC              namespace firstbad
#define BEGIN_NS_FIRSTBAD_NAMESPC        NS_FIRSTBAD_NAMESPC {
#define END_NS_FIRSTBAD_NAMESPC          }
#define USING_NS_FIRSTBAD_NAMESPC        using NS_FIRSTBAD_NAMESPC

#define NS_SECONDBAD_NAMESPC             namespace secondbad
#define BEGIN_NS_SECONDBAD_NAMESPC       BEGIN_NS_FIRSTBAD_NAMESPC NS_SECONDBAD_NAMESPC {
#define END_NS_SECONDBAD_NAMESPC         } END_NS_FIRSTBAD_NAMESPC
#define USING_NS_SECONDBAD_NAMESPC       USING_NS_FIRSTBAD_NAMESPC ; using NS_SECONDBAD_NAMESPC

#endif

becomes:

#ifndef badmacrosh
#define badmarcosh

#define NS_FIRSTBAD_NAMESPC namespace firstbad
#define BEGIN_NS_FIRSTBAD_NAMESPC                                                                                      \
    NS_FIRSTBAD_NAMESPC { #define END_NS_FIRSTBAD_NAMESPC }
#define USING_NS_FIRSTBAD_NAMESPC using NS_FIRSTBAD_NAMESPC

#define NS_SECONDBAD_NAMESPC namespace secondbad
#define BEGIN_NS_SECONDBAD_NAMESPC                                                                                     \
    BEGIN_NS_FIRSTBAD_NAMESPC NS_SECONDBAD_NAMESPC { #define END_NS_SECONDBAD_NAMESPC }                                \
    END_NS_FIRSTBAD_NAMESPC
#define USING_NS_SECONDBAD_NAMESPC                                                                                     \
    USING_NS_FIRSTBAD_NAMESPC;                                                                                         \
    using NS_SECONDBAD_NAMESPC

#endif

Header and .clang-format attached

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@mkurdej mkurdej added the invalid-code-generation Tool (e.g. clang-format) produced invalid code that no longer compiles label Jan 31, 2022
@mkurdej
Copy link
Member

mkurdej commented Feb 2, 2022

It is definitely related to brace wrapping, as I can reproduce it on current main (2022-02-02) with config:

BasedOnStyle:  LLVM
BreakBeforeBraces: Allman

or

BasedOnStyle:  LLVM
BreakBeforeBraces: Custom
BraceWrapping:
  AfterFunction: true

and smaller reproducer:

#define BEGIN        NS {
#define END          }

@mkurdej mkurdej added the confirmed Verified by a second party label Feb 2, 2022
@mkurdej
Copy link
Member

mkurdej commented Feb 2, 2022

FWIW, I have a quick fix that prevents merging together the two macro definitions (and hence the code does not break anymore), but the formatting is strange.
The code:

#define BEGIN        NS {
#define END          }

becomes

#define BEGIN                                                                  \
  NS                                                                           \
  {
#define END }

Config as above:

BasedOnStyle:  LLVM
BreakBeforeBraces: Custom
BraceWrapping:
  AfterFunction: true

This partial fix is to add:

    // Don't merge with a preprocessor directive.
    if (I[1]->Type == LT_PreprocessorDirective)
      return 0;

at the beginning of LineJoiner::tryMergeSimpleBlock.

@mkurdej mkurdej added the awaiting-review Has pending Phabricator review label Feb 3, 2022
@mkurdej
Copy link
Member

mkurdej commented Feb 3, 2022

Revision URI: https://reviews.llvm.org/D118879.

@mkurdej mkurdej closed this as completed in ca0d970 Feb 3, 2022
@github-actions github-actions bot removed the awaiting-review Has pending Phabricator review label Feb 3, 2022
owenca added a commit that referenced this issue Feb 4, 2022
The l_brace token in a macro definition should not be set to
TT_FunctionLBrace.

This patch could have fixed #42087.

Differential Revision: https://reviews.llvm.org/D118969
mem-frob pushed a commit to draperlaboratory/hope-llvm-project that referenced this issue Oct 7, 2022
Fixes llvm/llvm-project#42087.

Reviewed By: HazardyKnusperkeks, owenpan

Differential Revision: https://reviews.llvm.org/D118879
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang-format confirmed Verified by a second party invalid-code-generation Tool (e.g. clang-format) produced invalid code that no longer compiles
Projects
None yet
Development

No branches or pull requests

3 participants