[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-09-20 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment. In D154093#4648986 , @aeubanks wrote: > In D154093#4648931 , @eaeltsin > wrote: > >> This might have another issue with Verilog - >> >> < import "AAA-BBB" foo bar baz >

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-09-20 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment. In D154093#4648931 , @eaeltsin wrote: > This might have another issue with Verilog - > > < import "AAA-BBB" foo bar baz > --- > > import {"AAA-", > > "BBB"} foo bar

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-09-20 Thread Evgeny Eltsin via Phabricator via cfe-commits
eaeltsin added a comment. This might have another issue with Verilog - < import "AAA-BBB" foo bar baz --- > import {"AAA-", > "BBB"} foo bar baz I wonder if Verilog allows breaking strings in `import`? Repository: rG LLVM Github

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-09-14 Thread Evgeny Eltsin via Phabricator via cfe-commits
eaeltsin added a comment. This still misses contexts when string literal is required, for example https://github.com/search?q=repo%3Agoogle%2Fclosure-compiler%20%22%20must%20be%20a%20string%20literal%22&type=code I wonder, if splitting the literal with `+` is a good option at all. Repository:

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-09-12 Thread sstwcw via Phabricator via cfe-commits
sstwcw added a comment. In D154093#4644727 , @alexfh wrote: > This patch makes clang-format produce invalid JS/TS code > > In D154093#4644512 , @eaeltsin > wrote: > >> This introduces an invalid TS transformation

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-09-12 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment. This patch makes clang-format produce invalid JS/TS code In D154093#4644512 , @eaeltsin wrote: > This introduces an invalid TS transformation, from > > type x = 'ab'; > > to > > type x = ('a'+'b'); > > Which doesn't compile -

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-09-12 Thread Evgeny Eltsin via Phabricator via cfe-commits
eaeltsin added a comment. This introduces an invalid TS transformation, from type x = 'ab'; to type x = ('a'+'b'); Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154093/new/ https://reviews.llvm.org/D154093 __

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-09-04 Thread sstwcw via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes. Closed by commit rGddc80637ccbc: [clang-format] Break long string literals in C#, etc. (authored by sstwcw). Changed prior to commit: https://reviews.llvm.org/D154093?vs=553729&id=555795#toc Repository: rG LLVM Github

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-26 Thread sstwcw via Phabricator via cfe-commits
sstwcw updated this revision to Diff 553729. sstwcw added a comment. Stop using `SmallString` in the tests. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154093/new/ https://reviews.llvm.org/D154093 Files: clang/docs/ClangFormatStyleOptions.rst

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-24 Thread Owen Pan via Phabricator via cfe-commits
owenpan added a comment. In D154093#4615948 , @sstwcw wrote: > In the JavaScript tests that I added, it was wrong to use `SmallString`. > Would you prefer me changing it to `string` or expanding the 6 test cases so > we don't need a variable for the st

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-24 Thread sstwcw via Phabricator via cfe-commits
sstwcw added a comment. In the JavaScript tests that I added, it was wrong to use `SmallString`. Would you prefer me changing it to `string` or expanding the 6 test cases so we don't need a variable for the string? Shortly after I committed this patch, the server builds caught the problem in

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-24 Thread David Spickett via Phabricator via cfe-commits
DavidSpickett added a comment. This was causing failures on a large number of Linaro's bots. Judging by how widespread it was, reproducing could be as simple as adding `-DLLVM_ENABLE_ASSERTIONS=True` to your CMake config. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-23 Thread Owen Pan via Phabricator via cfe-commits
owenpan added a comment. @sstwcw this patch caused a crash in `FormatTestJS.StringLiteralConcatenation`: Assertion failed: ((!RequiresNullTerminator || BufEnd[0] == 0) && "Buffer is not null terminated!"), function init, file MemoryBuffer.cpp, line 54. Can you revert it if you can reproduce t

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-23 Thread sstwcw via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG16ccba51072b: [clang-format] Break long string literals in C#, etc. (authored by sstwcw). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay accepted this revision. MyDeveloperDay added a comment. I'm ok with this if @owenpan is Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154093/new/ https://reviews.llvm.org/D154093 ___ cfe-c

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-07 Thread sstwcw via Phabricator via cfe-commits
sstwcw updated this revision to Diff 547770. sstwcw added a comment. - Add tests for code in JavaScript template strings Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154093/new/ https://reviews.llvm.org/D154093 Files: clang/docs/ClangFormatStyl

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-07 Thread sstwcw via Phabricator via cfe-commits
sstwcw added inline comments. Comment at: clang/unittests/Format/FormatTestCSharp.cpp:221 TEST_F(FormatTestCSharp, CSharpFatArrows) { - verifyFormat("Task serverTask = Task.Run(async() => {"); + verifyIncompleteFormat("Task serverTask = Task.Run(async() => {"); verifyFormat

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-07 Thread sstwcw via Phabricator via cfe-commits
sstwcw updated this revision to Diff 547767. sstwcw marked 2 inline comments as done. sstwcw added a comment. - Add tests for code in JavaScript template strings Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154093/new/ https://reviews.llvm.org/D15

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-07 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments. Comment at: clang/unittests/Format/FormatTestCSharp.cpp:221 TEST_F(FormatTestCSharp, CSharpFatArrows) { - verifyFormat("Task serverTask = Task.Run(async() => {"); + verifyIncompleteFormat("Task serverTask = Task.Run(async() => {"); veri

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-06 Thread sstwcw via Phabricator via cfe-commits
sstwcw added a comment. @MyDeveloperDay Can you take a look at the last test in FormatTestCSharp.Attributes? I tried to enable breaking string literals by default. The long string got broken. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154093/

[PATCH] D154093: [clang-format] Break long string literals in C#, etc.

2023-08-06 Thread sstwcw via Phabricator via cfe-commits
sstwcw added a comment. In D154093#4544496 , @owenpan wrote: > In D154093#4542339 , @sstwcw wrote: > >> @owenpan What do you think about this revision especially the replacement >> part? > > See D154093#4544495 <