[PATCH] D19031: [clang-format] Flexible line endings

This revision was automatically updated to reflect the committed changes. Closed by commit rG358eaa3dcea1: [clang-format] Flexible line endings (authored by Cameron Desrochers ). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llv

[PATCH] D19031: [clang-format] Flexible line endings

MyDeveloperDay accepted this revision. MyDeveloperDay added a comment. This revision is now accepted and ready to land. 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 com

[PATCH] D19031: [clang-format] Flexible line endings

cameron314 added a comment. 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. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D19031/new/

[PATCH] D19031: [clang-format] Flexible line endings

cameron314 updated this revision to Diff 229533. cameron314 added a comment. Rebased diff on latest upstream. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D19031/new/ https://reviews.llvm.org/D19031 Files: clang/include/clang/Format/Format.h clang/lib/Format/Format.cpp clang/unit

[PATCH] D19031: [clang-format] Flexible line endings

MyDeveloperDay added a comment. 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/validat

[PATCH] D19031: [clang-format] Flexible line endings

STL_MSFT added a comment. 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), d

[PATCH] D19031: [clang-format] Flexible line endings

MyDeveloperDay added a subscriber: STL_MSFT. MyDeveloperDay added a comment. 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

[PATCH] D19031: [clang-format] Flexible line endings

cameron314 added a comment. @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 i

[PATCH] D19031: clang-format: Flexible line endings

MyDeveloperDay added a comment. 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

Re: [PATCH] D19031: clang-format: Flexible line endings

cameron314 added a comment. 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. http://revie

Re: [PATCH] D19031: clang-format: Flexible line endings

cameron314 added a comment. 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

Re: [PATCH] D19031: clang-format: Flexible line endings

djasper added a comment. 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

Re: [PATCH] D19031: clang-format: Flexible line endings

cameron314 added a comment. 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 o

Re: [PATCH] D19031: clang-format: Flexible line endings

djasper added a comment. 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 chang

Re: [PATCH] D19031: clang-format: Flexible line endings

cameron314 added a comment. 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 t

Re: [PATCH] D19031: clang-format: Flexible line endings

djasper added a comment. 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? http://reviews.llvm.org/D19031 ___ cfe-commits mailing

Re: [PATCH] D19031: clang-format: Flexible line endings

cameron314 added a comment. 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 ha