[clang-format] Flexible line endings

[mxbOctasic]

Summary

Line ending detection is now set with the `DeriveLineEnding` option.
CRLF can now be used as the default line ending by setting `UseCRLF`.
Without line ending detection, all line endings are converted according to the `UseCRLF` option.

[djasper]

I am not convinced that this behavior makes sense. It's not clang-format's task to clean up files with mixed line endings. I'd really like to avoid this complexity and most importantly adding additional configuration options. It doesn't fully apply, but please read:
http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options

[cameron314]

ClangFormat still needs to know what kind of newline to insert when reformatting code.
It already had the "auto-detect newline" behaviour; this patch simply allows the auto-detection to be overridden with an explicit setting. This is important for short files that have no newlines to start with, in which case the autodetection cannot work.

[djasper]

Can you elaborate more on what case this is actually addressing? Are you saying that you have a one-line file without linebreaks that you want clang-format to format?

[cameron314]

Sure :-)

The motivation behind this patch (and a few more upcoming ones) is to make ClangFormat (the library) more friendly for IDE integration (which is our primary use case), in particular for on-the-fly auto-formatting.

In an IDE auto-format setting, it's often the case that only fragments of the file at a time are being formatted. Often that means only a single line is passed as context. Or, sometimes, the file really is only one line to start with (e.g. formatting a file containing a one-line function declaration with the 'wrap after return type' option on needs to insert a newline).

[djasper]

Passing snippets / single lines from an IDE does not make sense. Don't try to go down this road. clang-format always needs the full file as context.

If you are already in an IDE, that IDE should control the line endings, not clang-format. Write a thin wrapper that changes clang-format's output to use the correct line endings.

[cameron314]

Too late ;-) We've successfully integrated it as the engine behind our auto-formatting feature, passing only the minimal context necessary.
We tried at first to supply the full file context, but that turned out to be much too slow in larger files. (We did a fair bit of testing with some of the real code our users have written.)

We can, of course, change the newlines on the IDE side instead (indeed, we already have a few transforms on both the input and output). But it seemed to us that it would make more sense to have ClangFormat generate the correct newlines in the first place given that this is what it already attempts to do with its newline detection feature. And we felt this minor extension would be useful to others.

[djasper]

It has very basic newline detection, but if possible, I'd like to not significantly increase that. Specifically, I don't think it is worth the complexity of additional configuration options that users have to worry about, if it can just do the right thing (which IMO, it currently does other than in a few some rare corner cases).

I am curious: Have you measured what makes clang-format slow if you give it the full file? Is that the file itself or the time clang-format spends on parsing it? Maybe some of the optimizations you now do in your IDE would actually be suited to clang-format itself.

[cameron314]

We did profile at one point, to see if it was something we could trivially speed up (it wasn't). Most of it was on the parsing/annotation side, yes (which makes sense, since that's the majority of the work when the format region itself is limited). I'm afraid I don't recall more details (this was a few months ago after we had just started). The memory usage spikes significantly, too. Anyway, we didn't want the size of the file to affect the insertion time of a semicolon if at all possible.

All of our optimization boils down to only giving ClangFormat the minimum amount of code necessary to format the statement or block we want. The way we determine this context is almost certainly not something you want to see in ClangFormat :-) It's quite heuristic in some places, and is very specific to C/C++. Sometimes it will even bail out and not format anything if the context spans too many (e.g. 2000+) lines. There's multiple levels of context involved, too (e.g. when declaration alignment is on, adjacent statements that look like declarations are also included in the context to get things to line up). And fake braces to set up the indentation correctly. It's also all written in C#, leveraging a large body of existing parsing code that we'd already written (for features like smart indent); things taken for granted in the IDE, like O(1) access to the tokens that make up a given line (which is constantly maintained as the user types instead of having to reparse from the top of the file), are simply not possible to do as efficiently in ClangFormat (barring persistent caching between calls, which of course is a whole can of worms in itself). Anyway, all that stuff is very "porcelain-y" code (to borrow a term from the git developers) that would no doubt vary significantly from IDE to IDE.

[cameron314]

Ooh, and I should also add, there's a non-trivial cost to grabbing the entire file contents as a string and then converting it to UTF-8. If ClangFormat was faster, this would certainly become a significant bottleneck that can't really be worked around.

[MyDeveloperDay]

Sorry I'm reviewing very old revisions, @mxbOctasic are you still interested in a patch like this?

> It's not clang-format's task to clean up files with mixed line endings

This is an interesting thought given that clang-format does exactly that based on how many ^M's there are in the file

if I make a file:

// A^M
// B^M
// C
// D

and have vim auto format on save when I come back it says

// A^M
// B^M
// C^M
// D

according to notepad++ its

but if I take this file and clang-format test.cpp > out.cpp I get

So I'm fine if the rule is it isn't "clang-format" job to adjust line endings... but if that's the case it should leave them alone, I think the 50/50 rule is a little crude at best!

I think it would be nice if clang-format could be setup to be "specific" and not random based on how large a section someone editing in a file in Visual studio without the correct setting.

For me, not having to remember to do a separate dos2unix would really help reduce the number of "Fix line endings" commits we see (especially on platforms where dos2unix isn't available in the shell)

This could really have helped the 1/2 million commits on github...(https://github.com/search?q=%22line+endings%22&type=Commits)

I think this patch like this is a good compromise, I'd personally just make UseCRLF and enum, I don't think it needs 2 options

enum {
    Derived   // |Do as we do now
    LF            // like doing a dos2unix
    CRLF        // like doing a unix2dos
}

Stil interested?

[cameron314]

@MyDeveloperDay: @mxbOctasic has moved on but I'm still maintaining this patch upstream, so I'm still interested in having it merged if possible.

The advantage of having two options is that a default line ending can still be specified when none can be derived (this is important to our use case where we sometimes pass individual lines to clang-format).

[MyDeveloperDay]

I suspect this patch might need a rebase, but I personally don't see anything wrong with it. I think this could really help.

I'm pretty sure the Unix line ending requirement is in almost every major style guide (I saw @STL_MSFT mention that they standardize on \r\n too) so I think it meets the criteria. (I know i'll personally use it as I live in a cross-platform shop and users forgetting to configure their Visual Studio is a major pain!)

If you're happy to rebase it, I'm happy to review it again.

[STL_MSFT]

MSVC's STL currently uses CRLF (DOS) line endings, not LF (Unix). I wrote a validator, https://github.com/microsoft/STL/blob/58bb49d63d92e7a0346a05af29816aeea6b4cf0f/tools/validate/validate.cpp , to detect LF files, mixed line endings (LF and CRLF in the same file), damaged endings (CR only), and enforcing one newline at the end of every file, because clang-format doesn't currently handle those whitespace issues.

[MyDeveloperDay]

In D19031#1746705, @STL_MSFT wrote:

MSVC's STL currently uses CRLF (DOS) line endings, not LF (Unix). I wrote a validator, https://github.com/microsoft/STL/blob/58bb49d63d92e7a0346a05af29816aeea6b4cf0f/tools/validate/validate.cpp , to detect LF files, mixed line endings (LF and CRLF in the same file), damaged endings (CR only), and enforcing one newline at the end of every file, because clang-format doesn't currently handle those whitespace issues.

@STL_MSFT I saw your tweet on the matter, I'd like to bring some of these rules into clang-format I think this patch might help, because it would be able to setup CRLF endings in the same way others would setup LF,

I also agree about the EOF, this can be a major pain as not all compilers complain and if you are doing cross-platform work developers accidentally forgetting them can cause a reasonable number of housekeeping post commits https://github.com/search?p=2&q=%22EOF%22&type=Commits

I like the idea of being able to turn off the derived rule, and using specific CRLF or LF rule to ensure conformance, (even if I'm just using clang-format to identify the issues in a pre merge check. i.e. having my .clang-format on my CI system being a little stricter)

[cameron314]

I've got a rebased diff but Phabricator won't let me attach it to this differential review (too old?). What do I do?

EDIT: Ah, it must be because I'm not the owner, despite it being editable by all.

[cameron314]

Rebased diff on latest upstream.

[MyDeveloperDay]

This LGTM, I think this could help more than people might at first realize. I love the idea that I can use clang-format in dry-run (-n) mode to now make line endings seem a compile error..

clang/lib/Format/Format.cpp

1360

The great thing about this is if I don't want derived line endings I save scanning through the code twice counting the line endings

clang/include/clang/Format/Format.h

   ///    true:                                  false:
   ///    vector<int> x{1, 2, 3, 4};     vs.     vector<int> x{ 1, 2, 3, 4 };
   ///    vector<T> x{{}, {}, {}, {}};           vector<T> x{ {}, {}, {}, {} };
   ///    f(MyMap[{composite, key}]);            f(MyMap[{ composite, key }]);
   ///    new int[3]{1, 2, 3};                   new int[3]{ 1, 2, 3 };
   /// \endcode
   bool Cpp11BracedListStyle;
 
+  /// \brief Analyze the formatted file for the most used line ending (``\r\n``
+  /// or ``\n``). ``UseCRLF`` is only used as a fallback if none can be derived.
+  bool DeriveLineEnding;
+
   /// If ``true``, analyze the formatted file for the most common
   /// alignment of ``&`` and ``*``.
   /// Pointer and reference alignment styles are going to be updated according
   /// to the preferences found in the file.
   /// ``PointerAlignment`` is then used only as fallback.
   bool DerivePointerAlignment;
 
   /// Disables formatting completely.
enum UseTabStyle {
     UT_ForIndentation,
     /// Use tabs only for line continuation and indentation.
     UT_ForContinuationAndIndentation,
     /// Use tabs whenever we need to fill whitespace that spans at least from
     /// one tab stop to the next one.
     UT_Always
   };
 
+  /// \brief Use ``\r\n`` instead of ``\n`` for line breaks.
+  /// Also used as fallback if ``DeriveLineEnding`` is true.
+  bool UseCRLF;
+
   /// The way to use tab characters in the resulting file.
   UseTabStyle UseTab;
 
   bool operator==(const FormatStyle &R) const {
     return AccessModifierOffset == R.AccessModifierOffset &&
            AlignAfterOpenBracket == R.AlignAfterOpenBracket &&
            AlignConsecutiveAssignments == R.AlignConsecutiveAssignments &&
            AlignConsecutiveDeclarations == R.AlignConsecutiveDeclarations &&
return AccessModifierOffset == R.AccessModifierOffset &&
            ColumnLimit == R.ColumnLimit && CommentPragmas == R.CommentPragmas &&
            BreakInheritanceList == R.BreakInheritanceList &&
            ConstructorInitializerAllOnOneLineOrOnePerLine ==
                R.ConstructorInitializerAllOnOneLineOrOnePerLine &&
            ConstructorInitializerIndentWidth ==
                R.ConstructorInitializerIndentWidth &&
            ContinuationIndentWidth == R.ContinuationIndentWidth &&
            Cpp11BracedListStyle == R.Cpp11BracedListStyle &&
+           DeriveLineEnding == R.DeriveLineEnding &&
            DerivePointerAlignment == R.DerivePointerAlignment &&
            DisableFormat == R.DisableFormat &&
            ExperimentalAutoDetectBinPacking ==
                R.ExperimentalAutoDetectBinPacking &&
            FixNamespaceComments == R.FixNamespaceComments &&
            ForEachMacros == R.ForEachMacros &&
            IncludeStyle.IncludeBlocks == R.IncludeStyle.IncludeBlocks &&
            IncludeStyle.IncludeCategories == R.IncludeStyle.IncludeCategories &&
return AccessModifierOffset == R.AccessModifierOffset &&
            SpacesBeforeTrailingComments == R.SpacesBeforeTrailingComments &&
            SpacesInAngles == R.SpacesInAngles &&
            SpacesInContainerLiterals == R.SpacesInContainerLiterals &&
            SpacesInCStyleCastParentheses == R.SpacesInCStyleCastParentheses &&
            SpacesInParentheses == R.SpacesInParentheses &&
            SpacesInSquareBrackets == R.SpacesInSquareBrackets &&
            Standard == R.Standard && TabWidth == R.TabWidth &&
            StatementMacros == R.StatementMacros && UseTab == R.UseTab &&
+           UseCRLF == R.UseCRLF &&
            TypenameMacros == R.TypenameMacros;
   }
 
   llvm::Optional<FormatStyle> GetLanguageStyle(LanguageKind Language) const;
 
   // Stores per-language styles. A FormatStyle instance inside has an empty
   // StyleSet. A FormatStyle instance returned by the Get method has its
   // StyleSet set to a copy of the originating StyleSet, effectively keeping the

clang/lib/Format/Format.cpp

static void mapping(IO &IO, FormatStyle &Style) {
     IO.mapOptional("CommentPragmas", Style.CommentPragmas);
     IO.mapOptional("CompactNamespaces", Style.CompactNamespaces);
     IO.mapOptional("ConstructorInitializerAllOnOneLineOrOnePerLine",
                    Style.ConstructorInitializerAllOnOneLineOrOnePerLine);
     IO.mapOptional("ConstructorInitializerIndentWidth",
                    Style.ConstructorInitializerIndentWidth);
     IO.mapOptional("ContinuationIndentWidth", Style.ContinuationIndentWidth);
     IO.mapOptional("Cpp11BracedListStyle", Style.Cpp11BracedListStyle);
+    IO.mapOptional("DeriveLineEnding", Style.DeriveLineEnding);
     IO.mapOptional("DerivePointerAlignment", Style.DerivePointerAlignment);
     IO.mapOptional("DisableFormat", Style.DisableFormat);
     IO.mapOptional("ExperimentalAutoDetectBinPacking",
                    Style.ExperimentalAutoDetectBinPacking);
     IO.mapOptional("FixNamespaceComments", Style.FixNamespaceComments);
     IO.mapOptional("ForEachMacros", Style.ForEachMacros);
     IO.mapOptional("IncludeBlocks", Style.IncludeStyle.IncludeBlocks);
     IO.mapOptional("IncludeCategories", Style.IncludeStyle.IncludeCategories);
static void mapping(IO &IO, FormatStyle &Style) {
     IO.mapOptional("SpacesInCStyleCastParentheses",
                    Style.SpacesInCStyleCastParentheses);
     IO.mapOptional("SpacesInParentheses", Style.SpacesInParentheses);
     IO.mapOptional("SpacesInSquareBrackets", Style.SpacesInSquareBrackets);
     IO.mapOptional("Standard", Style.Standard);
     IO.mapOptional("StatementMacros", Style.StatementMacros);
     IO.mapOptional("TabWidth", Style.TabWidth);
     IO.mapOptional("TypenameMacros", Style.TypenameMacros);
+    IO.mapOptional("UseCRLF", Style.UseCRLF);
     IO.mapOptional("UseTab", Style.UseTab);
   }
 };
 
 template <> struct MappingTraits<FormatStyle::BraceWrappingFlags> {
   static void mapping(IO &IO, FormatStyle::BraceWrappingFlags &Wrapping) {
     IO.mapOptional("AfterCaseLabel", Wrapping.AfterCaseLabel);
     IO.mapOptional("AfterClass", Wrapping.AfterClass);
FormatStyle getLLVMStyle(FormatStyle::LanguageKind Language) {
   LLVMStyle.BreakStringLiterals = true;
   LLVMStyle.ColumnLimit = 80;
   LLVMStyle.CommentPragmas = "^ IWYU pragma:";
   LLVMStyle.CompactNamespaces = false;
   LLVMStyle.ConstructorInitializerAllOnOneLineOrOnePerLine = false;
   LLVMStyle.ConstructorInitializerIndentWidth = 4;
   LLVMStyle.ContinuationIndentWidth = 4;
   LLVMStyle.Cpp11BracedListStyle = true;
+  LLVMStyle.DeriveLineEnding = true;
   LLVMStyle.DerivePointerAlignment = false;
   LLVMStyle.ExperimentalAutoDetectBinPacking = false;
   LLVMStyle.FixNamespaceComments = true;
   LLVMStyle.ForEachMacros.push_back("foreach");
   LLVMStyle.ForEachMacros.push_back("Q_FOREACH");
   LLVMStyle.ForEachMacros.push_back("BOOST_FOREACH");
   LLVMStyle.IncludeStyle.IncludeCategories = {
       {"^\"(llvm|llvm-c|clang|clang-c)/", 2, 0},
FormatStyle getLLVMStyle(FormatStyle::LanguageKind Language) {
   LLVMStyle.NamespaceIndentation = FormatStyle::NI_None;
   LLVMStyle.ObjCBinPackProtocolList = FormatStyle::BPS_Auto;
   LLVMStyle.ObjCBlockIndentWidth = 2;
   LLVMStyle.ObjCSpaceAfterProperty = false;
   LLVMStyle.ObjCSpaceBeforeProtocolList = true;
   LLVMStyle.PointerAlignment = FormatStyle::PAS_Right;
   LLVMStyle.SpacesBeforeTrailingComments = 1;
   LLVMStyle.Standard = FormatStyle::LS_Latest;
+  LLVMStyle.UseCRLF = false;
   LLVMStyle.UseTab = FormatStyle::UT_Never;
   LLVMStyle.ReflowComments = true;
   LLVMStyle.SpacesInParentheses = false;
   LLVMStyle.SpacesInSquareBrackets = false;
   LLVMStyle.SpaceInEmptyBlock = false;
   LLVMStyle.SpaceInEmptyParentheses = false;
   LLVMStyle.SpacesInContainerLiterals = true;
   LLVMStyle.SpacesInCStyleCastParentheses = false;
analyze(TokenAnnotator &Annotator,
     AffectedRangeMgr.computeAffectedLines(AnnotatedLines);
     for (unsigned i = 0, e = AnnotatedLines.size(); i != e; ++i) {
       Annotator.calculateFormattingInformation(*AnnotatedLines[i]);
     }
     Annotator.setCommentLineLevels(AnnotatedLines);
 
     WhitespaceManager Whitespaces(
         Env.getSourceManager(), Style,
-        inputUsesCRLF(Env.getSourceManager().getBufferData(Env.getFileID())));
+        Style.DeriveLineEnding ?
+          inputUsesCRLF(Env.getSourceManager().getBufferData(Env.getFileID()),
+                        Style.UseCRLF) :
+          Style.UseCRLF);
     ContinuationIndenter Indenter(Style, Tokens.getKeywords(),
                                   Env.getSourceManager(), Whitespaces, Encoding,
                                   BinPackInconclusiveFunctions);
     unsigned Penalty =
         UnwrappedLineFormatter(&Indenter, &Whitespaces, Style,
                                Tokens.getKeywords(), Env.getSourceManager(),
                                Status)
             .format(AnnotatedLines, /*DryRun=*/false,
                     /*AdditionalIndent=*/0,
                     /*FixBadIndentation=*/false,
                     /*FirstStartColumn=*/Env.getFirstStartColumn(),
                     /*NextStartColumn=*/Env.getNextStartColumn(),
                     /*LastStartColumn=*/Env.getLastStartColumn());
     for (const auto &R : Whitespaces.generateReplacements())
       if (Result.add(R))
         return std::make_pair(Result, 0);
     return std::make_pair(Result, Penalty);
   }
 
 private:
-  static bool inputUsesCRLF(StringRef Text) {
-    return Text.count('\r') * 2 > Text.count('\n');
+  static bool inputUsesCRLF(StringRef Text, bool DefaultToCRLF) {
+    size_t LF = Text.count('\n');
+    size_t CR = Text.count('\r') * 2;
+    return LF == CR ? DefaultToCRLF : CR > LF;
   }
 
   bool
   hasCpp03IncompatibleFormat(const SmallVectorImpl<AnnotatedLine *> &Lines) {
     for (const AnnotatedLine *Line : Lines) {
       if (hasCpp03IncompatibleFormat(Line->Children))
         return true;
       for (FormatToken *Tok = Line->First->Next; Tok; Tok = Tok->Next) {

clang/unittests/Format/FormatTest.cpp

TEST_F(FormatTest, ParsesConfigurationBools) {
   CHECK_PARSE_BOOL(AllowShortLoopsOnASingleLine);
   CHECK_PARSE_BOOL(BinPackArguments);
   CHECK_PARSE_BOOL(BinPackParameters);
   CHECK_PARSE_BOOL(BreakAfterJavaFieldAnnotations);
   CHECK_PARSE_BOOL(BreakBeforeTernaryOperators);
   CHECK_PARSE_BOOL(BreakStringLiterals);
   CHECK_PARSE_BOOL(CompactNamespaces);
   CHECK_PARSE_BOOL(ConstructorInitializerAllOnOneLineOrOnePerLine);
+  CHECK_PARSE_BOOL(DeriveLineEnding);
   CHECK_PARSE_BOOL(DerivePointerAlignment);
   CHECK_PARSE_BOOL_FIELD(DerivePointerAlignment, "DerivePointerBinding");
   CHECK_PARSE_BOOL(DisableFormat);
   CHECK_PARSE_BOOL(IndentCaseLabels);
   CHECK_PARSE_BOOL(IndentGotoLabels);
   CHECK_PARSE_BOOL(IndentWrappedFunctionNames);
   CHECK_PARSE_BOOL(KeepEmptyLinesAtTheStartOfBlocks);
   CHECK_PARSE_BOOL(ObjCSpaceAfterProperty);
TEST_F(FormatTest, ParsesConfigurationBools) {
   CHECK_PARSE_BOOL(SpaceAfterCStyleCast);
   CHECK_PARSE_BOOL(SpaceAfterTemplateKeyword);
   CHECK_PARSE_BOOL(SpaceAfterLogicalNot);
   CHECK_PARSE_BOOL(SpaceBeforeAssignmentOperators);
   CHECK_PARSE_BOOL(SpaceBeforeCpp11BracedList);
   CHECK_PARSE_BOOL(SpaceBeforeCtorInitializerColon);
   CHECK_PARSE_BOOL(SpaceBeforeInheritanceColon);
   CHECK_PARSE_BOOL(SpaceBeforeRangeBasedForLoopColon);
+  CHECK_PARSE_BOOL(UseCRLF);
 
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, AfterCaseLabel);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, AfterClass);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, AfterEnum);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, AfterFunction);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, AfterNamespace);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, AfterObjCDeclaration);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, AfterStruct);
EXPECT_EQ("/*\r\n"
                    "an extra carriage return\r\n"
                    "*/\r\n"));
   EXPECT_EQ("/*\r\n"
             "\r\n"
             "*/",
             format("/*\r\n"
                    "    \r\r\r\n"
                    "*/"));
+
+  FormatStyle style = getLLVMStyle();
+
+  style.DeriveLineEnding = true;
+  style.UseCRLF = false;
+  EXPECT_EQ("union FooBarBazQux {\n"
+            "  int foo;\n"
+            "  int bar;\n"
+            "  int baz;\n"
+            "};",
+            format("union FooBarBazQux {\r\n"
+                   "  int foo;\n"
+                   "  int bar;\r\n"
+                   "  int baz;\n"
+                   "};",
+                   style));
+  style.UseCRLF = true;
+  EXPECT_EQ("union FooBarBazQux {\r\n"
+            "  int foo;\r\n"
+            "  int bar;\r\n"
+            "  int baz;\r\n"
+            "};",
+            format("union FooBarBazQux {\r\n"
+                   "  int foo;\n"
+                   "  int bar;\r\n"
+                   "  int baz;\n"
+                   "};",
+                   style));
+
+  style.DeriveLineEnding = false;
+  style.UseCRLF = false;
+  EXPECT_EQ("union FooBarBazQux {\n"
+            "  int foo;\n"
+            "  int bar;\n"
+            "  int baz;\n"
+            "  int qux;\n"
+            "};",
+            format("union FooBarBazQux {\r\n"
+                   "  int foo;\n"
+                   "  int bar;\r\n"
+                   "  int baz;\n"
+                   "  int qux;\r\n"
+                   "};",
+                   style));
+  style.UseCRLF = true;
+  EXPECT_EQ("union FooBarBazQux {\r\n"
+            "  int foo;\r\n"
+            "  int bar;\r\n"
+            "  int baz;\r\n"
+            "  int qux;\r\n"
+            "};",
+            format("union FooBarBazQux {\r\n"
+                   "  int foo;\n"
+                   "  int bar;\r\n"
+                   "  int baz;\n"
+                   "  int qux;\n"
+                   "};",
+                   style));
+
+  style.DeriveLineEnding = true;
+  style.UseCRLF = false;
+  EXPECT_EQ("union FooBarBazQux {\r\n"
+            "  int foo;\r\n"
+            "  int bar;\r\n"
+            "  int baz;\r\n"
+            "  int qux;\r\n"
+            "};",
+            format("union FooBarBazQux {\r\n"
+                   "  int foo;\n"
+                   "  int bar;\r\n"
+                   "  int baz;\n"
+                   "  int qux;\r\n"
+                   "};",
+                   style));
+  style.UseCRLF = true;
+  EXPECT_EQ("union FooBarBazQux {\n"
+            "  int foo;\n"
+            "  int bar;\n"
+            "  int baz;\n"
+            "  int qux;\n"
+            "};",
+            format("union FooBarBazQux {\r\n"
+                   "  int foo;\n"
+                   "  int bar;\r\n"
+                   "  int baz;\n"
+                   "  int qux;\n"
+                   "};",
+                   style));
 }
 
 TEST_F(FormatTest, MunchSemicolonAfterBlocks) {
   verifyFormat("MY_CLASS(C) {\n"
                "  int i;\n"
                "  int j;\n"
                "};");
 }