Apologies @jdenny, the failure was occurring on a private build job and has no public access. The test failure can be found below:

Updated after jdenny's suggested regex change.

Intermittent error below:

[09:50:05] :	 [Step 3/3] next:10'0                     X error: no match found
[09:50:05] :	 [Step 3/3]           11:  "elapsed": 7.295608520507812e-05,

Thanks that LGTM.

I think my comment got eaten. Sorry for the delay @jhenderson. I've had a look, particularly at the section highlighted, and I this is the best place for this check. The best I can suggest is the use of a lambda or new function to tidy the IA_AddNewMember and IA_MoveNewMember cases. Something like:

auto handleNewMembers = [&](auto Members, auto MemberI, auto Child) {
  NewArchiveMember NM = getArchiveMember(*MemberI);
  if (isValidInBitMode(NM))
    addMember(Members, NM);
  else {
    // If a new member is not a valid object for the bit mode, add the old
    // member back.
    warnInvalidObjectForFileMode(*MemberI);
    addChildMember(Members, Child,
                   /*FlattenArchive=*/Thin);
  }
};

The issue stemmed from the output of sort differing between OS, removing it's use should fix things.

Currently testing on other machines.

Thanks, reverting

Removed missed use of %t.

Combined tests into one file, added us of --implicit-check-not, supressed archive creation warnings and fixed comments.

Fixed whitespace, comments and use of empty mri script.

Updated error message check.

Updated with use of --match-full-lines.

Fixed whitespace, added UNSUPPORTED: system-aix, placed rm, split-file, mkdir on one line, added explicit prefix and improved error message.

Fixed comments, added use of errc_NOENT and COUNT-2, added missing coverage of SAVE between calls to CREATE and improved error message.

Thanks for fixing this Ben, once James' suggestions are fixed it LGTM.

@urnathan I've created the ticket https://github.com/llvm/llvm-project/issues/55171 regarding the mangling issue. Just to note here, above I mentioned that I thought the mangled output matched GCC but this is not the case.

Updated with urnathan's suggestion.

I now see what you mean @dblaikie . I believe the mangling is functioning correctly and it's output matches GCC, it is the demangling that is the issue. By following @urnathan's code suggestion the demangled output will differ but I don't think this should be a problem as they are equivalent?

This looks like a good change to me, just needs that ranlib test fixing.

Apologies for the delay in response and thank you for your input @dblaikie and @urnathan.

Move testing to area suggested by @urnathan.

Fixed failing test and @jhenderson's other points.

I am not so familiar with this part of LLVM, I think this testing may belong elsewhere but I am unsure where that would be.

Updated after https://reviews.llvm.org/D123778 was accepted and committed.

Good idea @MaskRay, I've split that into https://reviews.llvm.org/D123778 and will update this one when D123778 is complete.

Corrected comments including replacing use of "full archive" with "regular archive" as suggested. To remain consistent two tests have been renamed to use the term "regular". The checks for "thinness" in llvm-ar.cpp now only applies for write commands.

The following tests have been modified:

• flatten-thin-archive.test now explicitly checks that %t.a is thin after the other archives have been added.
• full-to-thin-archive.test uses Inputs/a.txt as an input rather than itself as spurious passes could have occurred when looking for strings contained in the archive file. Corrected a comment, added a test case for an existing archive and a case attempting to convert an existing archive.
• thin-to-full-archive.test now tests the contents to ensure the thin archives member have been added and not the archive itself. Added a test case for an existing archive and a case attempting to convert an existing archive.

Fixed the description after abrachet's comment and updated the help output to mirror the change.

LGTM

To be clear this new output is an approximation for cases in which the canonical line number is 0 and so not too helpful to the user. I wanted to suggest this functionality as we have seen cases in which this new option would be useful to a user. Suggestions for a better name than --approximate-missing-line-numbers would also be appreciated.

@MaskRay Thanks for clarifying.

Hi @MaskRay, apologies for the wait in this review. The change LGTM. Regarding the implicit conversion from thin to full archives I think there is a problem there, I've created https://reviews.llvm.org/D118693 to discuss it further.

I believe Gnu-ar commands without T on thin archives do not auto convert to "full" archives:

Hi @MaskRay, apologies for the wait in this review. I think James brought up a good point regarding gnu ar still using T. I realise that when moving towards consistency someone has to go first, but it maybe worth us waiting until they make the change so we maintain compatibility. Do we know if they have plans to move over to --thin?

This issue was resolved.

Due to a private patch we were seeing this warning cause a test failure, hence this diff.

LGTM but I will hold of accepting this revision until James has seen the responses.

I understand your hesitation @jhenderson regarding the loss of the short option, maybe a replacement short option could be found?