Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Fixed another bug and added some unit tests. Also updated ReleaseNotes.rst and addressed some review comments.
Will extend this option to support C#, Java, and JavaScript using the underscore character _ as the separator.
clang/unittests/Format/FormatTest.cpp | ||
---|---|---|
25124 ↗ | (On Diff #484841) | If this test will grow to, say, 100+ lines, it’ll be worth the overhead. Meanwhile, we can move quit a few other much large tests out into their own files. |
25166 ↗ | (On Diff #484841) | Will do. |
- Adds support for C#, Java, and JavaScript using _.
- Adds support for only formatting affected ranges.
- Simplifies `IntegerLiteralSeparatorFixer::format()`.
- Adds more assertions and makes minor efficiency improvements.
- Fixed an assertion failure.
- Added unit tests .
- Moved all unit tests to another file.
Cleaned up the unit tests a little bit:
- Made them a little more varied.
- Removed some overlapping test cases.
- Removed integer literal suffixes for JavaScript.
- Added an octal BigInt test case for JavaScript.
This seems to break tests everywhere, eg http://45.33.8.238/linux/95289/step_7.txt
Please take a look and revert for now if it takes a while to fix.
I had run FormatTests on Windows and macOS without any problems and don't understand why the build bots failed. I will disable the FixRanges test as a workaround.
FWIW it also fails on Windows and macOS on my bots: http://45.33.8.238/macm1/51645/step_7.txt http://45.33.8.238/win/72399/step_7.txt
If the test is failing, why not revert the commit for now instead of disabling the test? That's what we usually do.
It was also failing on the official bots:
https://lab.llvm.org/buildbot/#/builders/109/builds/54291
I couldn't reproduce the failure until I ran the unit tests in the Release build. You are right though that I should have just reverted the commit.
clang/lib/Format/IntegerLiteralSeparatorFixer.cpp | ||
---|---|---|
82–83 | I should allocate memory for the Token object as shown but instead had Token Tok; before. |
clang/lib/Format/IntegerLiteralSeparatorFixer.cpp | ||
---|---|---|
82–83 | But why? What is different? |
It turns out that the memory bug had nothing to do with whether to use the stack or heap memory for the Token object. The culprit was passing getFormattingLangOpts(Style) directly to the Lexer constructor. I suppose in the Release build the copying of the returned LangOptions object is optimized out.
clang/lib/Format/IntegerLiteralSeparatorFixer.cpp | ||
---|---|---|
82–83 | Thanks for asking! It made me find the real cause. |
clang/lib/Format/IntegerLiteralSeparatorFixer.cpp | ||
---|---|---|
82–83 | No problem! ;) |
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
3168–3171 | This is causing the Sphinx build to fail: Warning, treated as error: https://lab.llvm.org/buildbot/#/builders/92/builds/38032 I think you need to remove one leading whitespace from line 3170 so that 0 aligns with < from the line above. |
This is causing the Sphinx build to fail:
Warning, treated as error:
/home/buildbot/llvm-build-dir/clang-sphinx-docs/llvm/build/tools/clang/docs/ClangFormatStyleOptions.rst:3170:Unexpected indentation.
https://lab.llvm.org/buildbot/#/builders/92/builds/38032
I think you need to remove one leading whitespace from line 3170 so that 0 aligns with < from the line above.