This is an archive of the discontinued LLVM Phabricator instance.

[clang-format] Adds a formatter for aligning arrays of structs
ClosedPublic

Authored by feg208 on May 4 2021, 4:08 PM.

Details

Summary

This adds a new formatter to arrange array of struct initializers into neat columns

Diff Detail

Unit TestsFailed

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
clang/unittests/Format/FormatTest.cpp
16626

What's missing is to format your last code with a column limit of 20 or so.

Regards using EXPECT_EQ:

EXPECT_EQ("test demo[] = {\n"
      "    {56, 23,    \"hello world i am a very long line that really, in any "
      "\"\n"
      "                \"just world, ought be split over multiple lines\" },\n"
      "    {-1, 93463, \"world\"                                          },\n"
      "    {7,  5,     \"!!\"                                             },\n"
      "};\n",
format("test demo[] = {{56, 23, \"hello world i am a very long line that really, in any just world, ought be split over multiple lines\"},{-1, 93463, \"world\"},{7, 5, \"!!\"},};", Style));

This should be done with ColumnLimit 0, 20, 100.

With verifyFormat you verify that the formatting is stable, but especially with no column limit there is often no stable.

curdeius added inline comments.May 7 2021, 1:04 AM
clang/docs/ReleaseNotes.rst
259–260
clang/lib/Format/UnwrappedLineFormatter.cpp
920–923 ↗(On Diff #343534)

Having this in a function seems like a bad idea, it just makes the code less readable. Please inline.

clang/unittests/Format/FormatTest.cpp
16605

Personally, I'm not really fond of testing all the combinations of styles. It adds little value to those tests.
I find it interesting to find problematic edge cases (which then should be added to the test suite "manually").
Also, when a test like this fails, it would be hard to see with which style it failed.

16678

Please add a test with preprocessor directives, e.g.:

verifyFormat("struct test demo[] = {\n"
             "    {56, 23,    \"hello\" },\n"
             "#if X\n"
             "    {-1, 93463, \"world\" },\n"
             "#endif\n"
             "    {7,  5,     \"!!\"    }\n"
             "};\n",
             Style);
16686

Nit: "ought to be" :).

feg208 marked 4 inline comments as done.May 7 2021, 1:12 PM

I think I have all the tests and requested review comments rolled up

clang/unittests/Format/FormatTest.cpp
16605

I think it could be constexpr (thats the direction I originally started which lead to much moaning about the lack of fold expressions) however getLLVMStyle() is not constexpr and it felt inappropriate for this commit to change the interface to that function even if the change were relatively harmless.

feg208 updated this revision to Diff 343747.May 7 2021, 1:12 PM

Added more tests and addressed review comments

feg208 updated this revision to Diff 343748.May 7 2021, 1:15 PM
feg208 marked an inline comment as done.

Oops missed a request

feg208 added a comment.May 7 2021, 1:15 PM

Missed a request in the release notes

HazardyKnusperkeks requested changes to this revision.May 8 2021, 1:23 AM
HazardyKnusperkeks added inline comments.
clang/unittests/Format/FormatTest.cpp
16605

Also, when a test like this fails, it would be hard to see with which style it failed.

That is a valid point. You should only test some combinations.

16718

But this line is longer than 20! This test should fail, shouldn't it?

This revision now requires changes to proceed.May 8 2021, 1:23 AM

Something which just came to my mind. Since you wrote your own LineFormatter, you have to add test cases for all kinds of indention and wrapping. It seems that the string wrapping does not happen, how about comments? Are classes, namespaces, functions, etc. correctly indented with various configurations?

Given my expectations I think the alignment has to happen differently, but I'm happy to be proven wrong.

feg208 added a comment.May 8 2021, 8:59 AM

I still need to handle the 20 character case appropriately

clang/unittests/Format/FormatTest.cpp
16605

I can certainly strip it down to corner cases. I guess I am not clear on which ones I should focus on. When I implemented this none of the combinations created problems. I could pick a few at random? But that doesn't feel like an improvement.

16718

It should. When I use the command line invocation I get different output

#include <array>
struct test {
  int a, b;
  const char *c;
};

int main(
    int,
    const char **) {
  std::array<
      struct test,
      3>
      demo;
  demo = std::array<
      struct test,
      3>{
      test{
          56, 23,
          "hello "
          "world i "
          "am a "
          "very "
          "long "
          "line "
          "that "
          "really, "
          "in any "
          "just "
          "world, "
          "ought "
          "to be "
          "split "
          "over "
          "multiple"
          " lines"},
      test{-1,
           93463,
           "world"},
      test{7, 5,
           "!!"},
  };
}

I will investigate

Something which just came to my mind. Since you wrote your own LineFormatter, you have to add test cases for all kinds of indention and wrapping. It seems that the string wrapping does not happen, how about comments? Are classes, namespaces, functions, etc. correctly indented with various configurations?

Given my expectations I think the alignment has to happen differently, but I'm happy to be proven wrong.

hmmmmmm I think you are correct. Or at least the path I am going down with getting the case of a 20 character column width is demanding adding a bunch of things that replicate what is already there. Does a more fruitful avenue look something like annotating the tokens?

This looks like a good start..

All your tests are 3x3 have you considered mixing it up a bit. i.e. 2x3, what is the impact on 1x5 and 5x1 ?

Also how about nested structs, I'm interested to see what happens

{56, 23, { "ABC", 35 }}
{57, 24, { "DEF", 36 }}

This looks like a good start..

Thanks. I am reworking it so I handle line breaking in a sane fashion and dropping the LineFormatter override since that really can't handle reformatting without reimplementing most of it

All your tests are 3x3 have you considered mixing it up a bit. i.e. 2x3, what is the impact on 1x5 and 5x1 ?

I am also adding a bunch more tests. I'll roll this in.

Also how about nested structs, I'm interested to see what happens

{56, 23, { "ABC", 35 }}
{57, 24, { "DEF", 36 }}

Will do. I added the braced initializer int constructor test to exercise the same code path. But it can't hurt to get this in there

This is a valiant effort, and I definitely don't want to discourage..especially as you shown a good understand of clang-format. Its been a long asked for feature.. but we should really ensure this covers the bulk of the complaints if possible..

For me I use this.. a search for clang-format off in github projects

https://github.com/search?q=clang-format+off

Status AbsGrad(const AttrSlice& attrs, FunctionDef* g) {
  // clang-format off
  return GradForUnaryCwise(g, {
      {{"sign"}, "Sign", {"x"}, {}, {"dy"}},
      {{"dx"}, "Mul", {"dy", "sign"}},
  });
  // clang-format on
}

https://github.com/lulzsec2012/tensorflow/blob/d68d869e397515655e9f41570f4db463df770563/tensorflow/core/ops/math_grad.cc

it would be my ideal if we could irradiate the need for these, as they heavily dominate.

clang/unittests/Format/FormatTest.cpp
16642

may be worth testing a case with comments at the end of each line

verifyFormat("struct test demo[3] = {\n"
                 "    {56, 23,    \"hello\" }, // first line\n"
                 "    {-1, 93463, \"world\" }, /* second line */\n"
                 "    {7,  5,     \"!!\"    } // at the end\n"
                 "};\n",
                 Style);
feg208 updated this revision to Diff 347208.May 22 2021, 11:06 AM

This reworks substantially this commit. I recognize there are lacking/broken
tests but I just would like to ensure that the general direction doesn't
seem likely to end in tears

feg208 updated this revision to Diff 347209.May 22 2021, 11:09 AM

Forgot to alter the documentation to reflect right justified column alignment

feg208 updated this revision to Diff 347211.May 22 2021, 12:35 PM

Adds some tests and fixes a broken test

feg208 updated this revision to Diff 347252.May 23 2021, 9:06 AM

Fixes/adds a test that yielded a seg fault and quiets some clang-tidy checks

This reworks substantially this commit. I recognize there are lacking/broken
tests but I just would like to ensure that the general direction doesn't
seem likely to end in tears

I'm not deep enough in clang-format and currently have not enough time to check that in depth. But why are you right aligning?

I would love to have a right aligning for numbers (or even better aligning around the decimal dot) in all my code, but strings I wouldn't want to right align.

This reworks substantially this commit. I recognize there are lacking/broken
tests but I just would like to ensure that the general direction doesn't
seem likely to end in tears

I'm not deep enough in clang-format and currently have not enough time to check that in depth. But why are you right aligning?

So the basic approach here is to add the column aligning at the point that the lines are broken to make sure that we can align to the indented, now broken, columns. The right alignment was the easier path (at the moment) since the spaces attached to tokens in the change list proceeded the token and since I was calculating the column size with spaces based on a pointer attached to the token in the same column. To left align at each column I'd need to look at the adjacent column to determine the right number of spaces.

I would love to have a right aligning for numbers (or even better aligning around the decimal dot) in all my code, but strings I wouldn't want to right align.

I think we could certainly do that. I guess at this point (and this is somewhat motivated by the fact that I don't, and probably shouldn't, have commit rights the to llvm repo) I think if we want to move this commit forward we ought to agree on a set of changes and subsequent tests that we can all be comfortable with that would make this a viable bit of code. I don't think it has deep problems in the sense the prior one did and so should be amenable to laundry listing what we need and I'll move it forward. I think this set of tests should be added/fixed:

A test where the line is broken in the middle and/or first column (line breaking is really the sticky bit)
Fixing the test where the 100 column limit doesn't format correctly
Adding a test with several arrays to format and varying the other alignment options to make sure that doesn't confuse anything

I guess a final question I have would be, if we get this list sorted who can/would be capable of committing this change to the repo?

feg208 updated this revision to Diff 347419.May 24 2021, 9:13 AM

clang-tidy and clang-format changes

This reworks substantially this commit. I recognize there are lacking/broken
tests but I just would like to ensure that the general direction doesn't
seem likely to end in tears

I'm not deep enough in clang-format and currently have not enough time to check that in depth. But why are you right aligning?

So the basic approach here is to add the column aligning at the point that the lines are broken to make sure that we can align to the indented, now broken, columns. The right alignment was the easier path (at the moment) since the spaces attached to tokens in the change list proceeded the token and since I was calculating the column size with spaces based on a pointer attached to the token in the same column. To left align at each column I'd need to look at the adjacent column to determine the right number of spaces.

I would love to have a right aligning for numbers (or even better aligning around the decimal dot) in all my code, but strings I wouldn't want to right align.

I think we could certainly do that. I guess at this point (and this is somewhat motivated by the fact that I don't, and probably shouldn't, have commit rights the to llvm repo) I think if we want to move this commit forward we ought to agree on a set of changes and subsequent tests that we can all be comfortable with that would make this a viable bit of code. I don't think it has deep problems in the sense the prior one did and so should be amenable to laundry listing what we need and I'll move it forward. I think this set of tests should be added/fixed:

A test where the line is broken in the middle and/or first column (line breaking is really the sticky bit)
Fixing the test where the 100 column limit doesn't format correctly
Adding a test with several arrays to format and varying the other alignment options to make sure that doesn't confuse anything

I guess a final question I have would be, if we get this list sorted who can/would be capable of committing this change to the repo?

As said, I would really love more advanced alignment options, but I think we should keep to what clang-format does now, left aligning.

The tests seem to be reasonable, a combination of previous (mis)alignment and comments (end of line and in the middle) should be added.

clang/lib/Format/TokenAnnotator.cpp
2656

I don't know if there are already NOLINTs in the code and if there should be, on a different change I saw there are some messages from clang-tidy in the existing code which are ignored (not NOLINTed). That's something maybe someone with more experience can answer.

2668

Although I'm not a big fan of it, I think the LLVM style is no braces for one line if and else.

2687

This one I'm against, just do what clang-tidy says remove the else. (Others may disagree.)

feg208 marked 2 inline comments as done.May 25 2021, 9:37 AM

The tests still need to be added

feg208 updated this revision to Diff 347709.May 25 2021, 9:37 AM

Addresses review comments

feg208 updated this revision to Diff 348020.EditedMay 26 2021, 10:52 AM

Still need to fix and add the tests I said I would but the comment tests are added

clang/lib/Format/FormatToken.cpp
86 ↗(On Diff #348020)

Personal style, don't know about LLVM. Same below.

clang/unittests/Format/FormatTest.cpp
16707

And a comment after the value?

16713

Or at the line end?

feg208 marked 3 inline comments as done.May 27 2021, 11:51 AM

I picked up most of these. One of the tests is already covered (I think) maybe I am misunderstanding

clang/unittests/Format/FormatTest.cpp
16713

I have this check up on lines 16384-16397

feg208 updated this revision to Diff 348346.May 27 2021, 11:51 AM
feg208 marked an inline comment as done.

Rolls up review comments

clang/unittests/Format/FormatTest.cpp
16713

Sorry for that, I just looked at the diff between the revisions. I perform full review only if we are near the final decision and don't have all things (especially all test cases) in memory.

feg208 updated this revision to Diff 349299.Jun 2 2021, 9:22 AM

I am of the view that this is complete. Or at a minimum all the tests that have
been requested pass and I would be surprised if there were gross errors or other
major things I have missed

feg208 updated this revision to Diff 349324.Jun 2 2021, 10:35 AM

oops left some debugging messages in

HazardyKnusperkeks requested changes to this revision.Jun 2 2021, 1:31 PM

I've added a few comments, and I would like to hear the opinion of others regarding the left or right alignment of the elements.

clang/lib/Format/ContinuationIndenter.cpp
603 ↗(On Diff #349324)

Please don't remove the empty lines.

clang/lib/Format/TokenAnnotator.cpp
733

Capital letter for variables.

733

Where does the 2 come from? How do we know that + 2 is always applicable? There should be an explanation, and an assert.

On another note, I would prefer std::next().

2663–2665

There are still braces.

2669

I think if you revert the condition and drop the else (because of the break) makes it more readable.

clang/lib/Format/TokenAnnotator.h
35

Add a trailing comma, so that future additions do not need to change this line.

clang/lib/Format/WhitespaceManager.h
256

For iterators prefix increment is really better than postfix.

This revision now requires changes to proceed.Jun 2 2021, 1:31 PM
feg208 marked 6 inline comments as done.Jun 2 2021, 2:04 PM

I rolled up the suggested changes.

clang/lib/Format/ContinuationIndenter.cpp
603 ↗(On Diff #349324)

I am sorry. I was peeling back previous changes and must have overdone it

clang/lib/Format/TokenAnnotator.cpp
2663–2665

blech I thought I got those. Sorry.

feg208 updated this revision to Diff 349373.Jun 2 2021, 2:04 PM
feg208 marked 2 inline comments as done.

Captured review comments

feg208 updated this revision to Diff 349374.Jun 2 2021, 2:06 PM
feg208 marked an inline comment as done.

Missed a request

feg208 added a comment.Jun 2 2021, 2:07 PM

one remaining

feg208 updated this revision to Diff 349434.Jun 2 2021, 5:41 PM
feg208 added a comment.Jun 2 2021, 5:41 PM

Adds a simple lit test for some sanity checks

clang/lib/Format/TokenAnnotator.cpp
737–740

I actually meant so. Because now this is even safe if the iterators are not random access anymore in the future.

clang/lib/Format/WhitespaceManager.cpp
1145–1146

I don't know how to do this in LLVM style, but maybe so?

feg208 updated this revision to Diff 349589.Jun 3 2021, 9:38 AM
feg208 marked 2 inline comments as done.

Grabs up some review comments and adds lit test

feg208 added a comment.Jun 3 2021, 9:39 AM

Got both of these

clang/lib/Format/TokenAnnotator.cpp
737–740

Oh I see. I sort of wondered about that but it didn't seem like a hill to die on.

clang/lib/Format/WhitespaceManager.cpp
1145–1146

So long as clang-format doesn't complain I am fine either way

feg208 updated this revision to Diff 349728.Jun 3 2021, 4:31 PM

Rebased against main

feg208 updated this revision to Diff 349730.Jun 3 2021, 4:35 PM

Had some invalid code in the lit test

Remains the issue with the alignment, I would like to know @MyDeveloperDay 's opinion on that. Should the values be right aligned, or left aligned? As far as I see all alignment in clang-format is left until now.

clang/lib/Format/WhitespaceManager.cpp
983

This is unneccessary. (But doesn't need a new revision until approved.)

1082

Same

Remains the issue with the alignment, I would like to know @MyDeveloperDay 's opinion on that. Should the values be right aligned, or left aligned? As far as I see all alignment in clang-format is left until now.

I think whatever you choose someone will ask for the opposite, maybe consider making it an option now while you are in the code and understand it.

Ok. Given @HazardyKnusperkeks comment I'll make the default be left alignment and update the tests accordingly

Ok. Given @HazardyKnusperkeks comment I'll make the default be left alignment and update the tests accordingly

You could add AlignArrayOfStructuresMemberAlignment Left:Right you have the code to right align, your about to change it to left align, seems like you've done all the work.

Better still how about having

ArraryMemberAligmentEnum AlignArrayOfStructures

of "None, Left and Right"

I find boolean options don't stay boolean for long!

Better still how about having

ArraryMemberAligmentEnum AlignArrayOfStructures

of "None, Left and Right"

I find boolean options don't stay boolean for long!

A strong +1.

feg208 added a comment.Jun 8 2021, 6:35 AM

Better still how about having

ArraryMemberAligmentEnum AlignArrayOfStructures

of "None, Left and Right"

I find boolean options don't stay boolean for long!

Yeah once I started doing the work this is exactly the path I am going down. Save the name. I should have it rolled up shortly.

Save the name. I should have it rolled up shortly.

You an keep the name, just change the type to be an enum

feg208 updated this revision to Diff 350746.Jun 8 2021, 5:21 PM

This alters the array alignment to allow for left alignment

feg208 updated this revision to Diff 350774.Jun 8 2021, 8:32 PM

Fixes from clang-tidy checks

curdeius added inline comments.Jun 9 2021, 12:43 AM
clang/docs/ClangFormatStyleOptions.rst
216–221

Don't forget to re-generate .rst.

MyDeveloperDay added inline comments.Jun 9 2021, 12:54 AM
clang/lib/Format/WhitespaceManager.h
234

Can ensure the comment starts with a capital and finishes with punctuation (I personally don't mind but I believe that is the convention)

275
292
311
314
feg208 updated this revision to Diff 350910.Jun 9 2021, 8:44 AM
feg208 marked 4 inline comments as done.

Gets some of the formatting issues. Still chasing a test issue.

feg208 added a comment.Jun 9 2021, 8:44 AM

Got some changes. The failing test is an open issue

clang/docs/ClangFormatStyleOptions.rst
216–221

I am sorry. I am not entirely sure what to check here? Should I regenerate the docs for the site and just ensure that they look ok?

feg208 updated this revision to Diff 350920.Jun 9 2021, 9:17 AM

Fixes the busted test

feg208 updated this revision to Diff 350924.Jun 9 2021, 9:25 AM

Ick. Missed a semi colon in the test

curdeius added inline comments.Jun 9 2021, 11:25 AM
clang/docs/ClangFormatStyleOptions.rst
216–221

It seems that you modified Format.h but didn't re-run clang/docs/tools/dump_format_style.py (example for Left is actually right-aligned).

feg208 updated this revision to Diff 350974.Jun 9 2021, 12:28 PM

Regenerated the mangled ClangFormatStyle.rst file

feg208 marked an inline comment as done.Jun 9 2021, 12:29 PM

addressed the remaining review comment

clang/docs/ClangFormatStyleOptions.rst
216–221

Got it. Sorry for the confusion.

curdeius accepted this revision.Jun 9 2021, 12:46 PM

LGTM. That's a great piece work @feg208. Thank you!

I've added many nit comments, but I didn't do it for all code comments.
Please check that all comments are full phrases (with full stops :) ) before landing.
Some comments are in .rst but you know that you need to update Format.h and then regenerate .rst :).
Also, don't hesitate to mark comments as done.

Do you need somebody to land it on your behalf?

clang/docs/ClangFormatStyleOptions.rst
213–218

This repetition of demo struct seems not very useful.

247

Nit. This can be done when landing. No need to update the patch just for this.

clang/include/clang/Format/Format.h
93
clang/lib/Format/FormatToken.h
434–442

Nits.

clang/lib/Format/WhitespaceManager.cpp
994
1005
1013–1014
1062
1064
clang/lib/Format/WhitespaceManager.h
185–190

Nit.

266

Nit.

This revision is now accepted and ready to land.Jun 9 2021, 12:46 PM
feg208 marked an inline comment as done.Jun 9 2021, 12:52 PM

LGTM. That's a great piece work @feg208. Thank you!

Awww thanks. I learned a lot from all the comments honestly. I appreciate the patience.

I've added many nit comments, but I didn't do it for all code comments.
Please check that all comments are full phrases (with full stops :) ) before landing.
Some comments are in .rst but you know that you need to update Format.h and then regenerate .rst :).
Also, don't hesitate to mark comments as done.

I'll roll these up.

Do you need somebody to land it on your behalf?

I do. I don't have commit rights

feg208 updated this revision to Diff 350984.Jun 9 2021, 1:05 PM
feg208 marked 11 inline comments as done.

Rolls up the remaining review comments

feg208 marked 3 inline comments as done.Jun 9 2021, 1:09 PM

All the review comments are addressed

If I can get someone to submit this on my behalf I think we can call it a day.

If I can get someone to submit this on my behalf I think we can call it a day.

Please post the name and email for the commit. And if no one else commits, I will do it on the weekend.

If I can get someone to submit this on my behalf I think we can call it a day.

Please post the name and email for the commit. And if no one else commits, I will do it on the weekend.

Fred Grim fgrim@apple.com

Thanks much

This revision was landed with ongoing or failed builds.Jun 13 2021, 12:14 PM
This revision was automatically updated to reflect the committed changes.
vitalybuka added inline comments.
clang/test/Format/struct-array-initializer.cpp
6

This test is very flaky https://lab.llvm.org/buildbot/#/builders/109

******************** TEST 'Clang :: Format/struct-array-initializer.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   grep -Ev "// *[A-Z-]+:" /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp    | /b/1/clang-x86_64-debian-fast/llvm.obj/bin/clang-format -style="{BasedOnStyle: LLVM, AlignArrayOfStructures: Right}" /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp    | /b/1/clang-x86_64-debian-fast/llvm.obj/bin/FileCheck -strict-whitespace -check-prefix=CHECK1 /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp
: 'RUN: at line 4';   grep -Ev "// *[A-Z-]+:" /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp    | /b/1/clang-x86_64-debian-fast/llvm.obj/bin/clang-format -style="{BasedOnStyle: LLVM, AlignArrayOfStructures: Left}" /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp    | /b/1/clang-x86_64-debian-fast/llvm.obj/bin/FileCheck -strict-whitespace -check-prefix=CHECK2 /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp
--
Exit Code: 141
Command Output (stderr):
--
+ : 'RUN: at line 1'
+ /b/1/clang-x86_64-debian-fast/llvm.obj/bin/clang-format '-style={BasedOnStyle: LLVM, AlignArrayOfStructures: Right}' /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp
+ grep -Ev '// *[A-Z-]+:' /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp
+ /b/1/clang-x86_64-debian-fast/llvm.obj/bin/FileCheck -strict-whitespace -check-prefix=CHECK1 /b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Format/struct-array-initializer.cpp
--
********************
feg208 added inline comments.Jun 14 2021, 8:34 PM
clang/test/Format/struct-array-initializer.cpp
6

Yeah. I added you to a review to alter it to something I think will be less of an issue. Thanks by the by for getting the unused NetWidth variable

The test is still intermittently failing on bots.
Is there some non-determinism in the change?
It may be a good idea to revert this.

Do we actually need this lit test? Mostly we only add lit tests when we add a new command line argument, I feel your are just testing what we also test in the unittests.

I think, at this point, the sensible thing to do is to pull the test. As @MyDeveloperDay points out it isn't really adding any value above and beyond the unit tests. If it were non-determinism in the change itself the unit tests would catch it. They test the same formatting and test for non-determinism explicitly. Yet they've never failed. And there are quite a few of them.

dyung added a subscriber: dyung.Jun 15 2021, 12:31 PM

Another +1 for it failing intermittently on the bot I watch over, llvm-clang-x86_64-sie-ubuntu-fast. Anything that can be done to stabilize the test or to remove it would be appreciated!

Another +1 for it failing intermittently on the bot I watch over, llvm-clang-x86_64-sie-ubuntu-fast. Anything that can be done to stabilize the test or to remove it would be appreciated!

I actually have two reviews up to remove the test https://reviews.llvm.org/D104295 or change it https://reviews.llvm.org/D104242 that have both been accepted but I don't have commit rights against llvm so I need to get someone to push them in. At this point removing the test is the least risky option. I am sorry for the delay and bother. Hopefully I can either get someone to put it in on my behalf or I'll get commit rights. I have followed the dev docs and emailed Chris.

MyDeveloperDay added a comment.EditedSep 24 2021, 11:14 AM

There are a number of bugs logged against this feature, are you still around to look into them?

https://bugs.llvm.org/show_bug.cgi?id=51926
https://bugs.llvm.org/show_bug.cgi?id=51935

I am. I'll jump on this over the weekend. Sorry been a bit buried in my day job