Revert "ci: Fix llvm detection on macOS CI"

[carlocab]

Fixed in Homebrew/homebrew-core#112154.

This reverts commit c20fb65.

CC @nirbheek

[eli-schwartz]

LGTM once CI passes.

[carlocab]

Looking at the CI log, I think this is installing an older version of LLVM that isn't fixed yet.

To avoid that, we can run brew update before doing brew install llvm. Or we can wait for GitHub to deploy a CI image that includes the fixed version of LLVM.

[codecov]

Codecov Report

Merging #10888 (859ee6a) into master (458dcf8) will decrease coverage by 7.42%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #10888      +/-   ##
==========================================
- Coverage   68.40%   60.97%   -7.43%     
==========================================
  Files         412      205     -207     
  Lines       87724    42862   -44862     
  Branches    19363     8815   -10548     
==========================================
- Hits        60005    26137   -33868     
+ Misses      23242    14682    -8560     
+ Partials     4477     2043    -2434     

Impacted Files	Coverage Δ
mesonbuild/modules/qt6.py	0.00% <0.00%> (-100.00%)	⬇️
mesonbuild/utils/win32.py	0.00% <0.00%> (-100.00%)	⬇️
mesonbuild/scripts/clangtidy.py	0.00% <0.00%> (-93.34%)	⬇️
mesonbuild/scripts/depscan.py	0.00% <0.00%> (-83.45%)	⬇️
mesonbuild/scripts/hotdochelper.py	0.00% <0.00%> (-81.49%)	⬇️
mesonbuild/modules/wayland.py	0.00% <0.00%> (-79.69%)	⬇️
mesonbuild/modules/windows.py	0.00% <0.00%> (-72.00%)	⬇️
mesonbuild/scripts/itstool.py	0.00% <0.00%> (-66.67%)	⬇️
mesonbuild/modules/hotdoc.py	0.00% <0.00%> (-65.83%)	⬇️
mesonbuild/templates/dlangtemplates.py	37.93% <0.00%> (-62.07%)	⬇️
... and 290 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[carlocab]

Yep, brew install llvm is still picking up an old version without the fix.

Let me know which of these two alternatives you prefer:

To avoid that, we can run brew update before doing brew install llvm. Or we can wait for GitHub to deploy a CI image that includes the fixed version of LLVM.

[nirbheek]

I approved the workflows, but they haven't been run yet.

[jpakkane]

The test failure seems related.

[eli-schwartz]

The failure doesn't seem to be remotely related, it's way too long to see in CI and Github appears to refuse to actually let me download the logs (just spends a long time loading and getting nowhere) but "Iteration" is a string that only appears in dumper.c, part of a non-llvm related test.

I do not know why rerunning the CI didn't clear the error if it is a flake, but I don't know what it could be if it's not a flake. Maybe rebasing would help?

[carlocab]

The failure doesn't seem to be remotely related

This is my impression too, but I haven't had the chance to take a close look at what is going on exactly. On the other hand, maybe this is what @nirbheek was referring to by "the linker just hangs" in #10879?

I did manage to download the logs for a previous run (with similar results) a few days ago: logs.tar.gz

I wasn't able to spot anything helpful, but maybe you'll see something.

[eli-schwartz]

The test failure seems to be logging tens of thousands of lines of "Iteration ...", which points to test cases/common/253 long output/ as the failing test because only failing tests actually get logged to the CI runner's console and end up in the Actions log.

This test case doesn't even look up an LLVM dependency, it builds one test file and checks that running it as a Meson test properly parses the TAP stream. The test file looks like this:

#include <stdio.h>

int main(void)
{
    for (int i = 0 ; i < 100000 ; i++)
        fprintf(stderr, "# Iteration %d to stderr\n", i + 1);

    printf("ok 1 - dumper to stderr\n");

    for (int i = 0 ; i < 100000 ; i++)
        fprintf(stdout, "# Iteration %d to stdout\n", i + 1);

    printf("ok 2 - dumper to stdout\n1..2\n");

    return 0;
}

This test file was successfully built, and runs in meson test, and outputs 100,000 lines, or perhaps a few less ;), and then at some point this fails, meson test prints the failing test's stdout/stderr and exits failure, and the test harness forwards that to the Actions console.

Why this test fails, I'm not sure without looking at the log. But it's not failing to link dumper.c into an executable, and it's not failing in anything related to LLVM.

[eli-schwartz]

From your uploaded logs:

2022-10-09T06:37:45.6561100Z # Iteration 99998 to stderr
2022-10-09T06:37:45.6561190Z # Iteration 99999 to stderr
2022-10-09T06:37:45.6561290Z # Iteration 100000 to stderr
2022-10-09T06:37:45.6561410Z ==============================================================================
2022-10-09T06:37:45.6561430Z 
2022-10-09T06:37:45.6561430Z 
2022-10-09T06:37:45.6561530Z Summary of Failures:
2022-10-09T06:37:45.6561540Z 
2022-10-09T06:37:45.6562060Z 118/2 dump-test   TIMEOUT        30.66s   killed by signal 15 SIGTERM
2022-10-09T06:37:45.6562380Z 119/2 dump-test-TAP TIMEOUT        30.72s   killed by signal 15 SIGTERM

So all iterations complete but nevertheless the test files are killed by SIGTERM after a timeout of 30 seconds? Why. What. How.

EDIT: Let's see if it magically passes after the rebase.

[carlocab]

Looks like rebasing worked?

[eli-schwartz]

Nice!

[carlocab]

Great. Feel free to ping me in the future if Homebrew breaks your CI again.