[ci] Disable tests with MSVC for now

[khaledhosny]

They have been broken for enough time now and they just make all changes have broken CI builds and people are habitually ignoring other failures.

[alerque]

Definitely a good idea. I meant to ask about this while working on #2678 (which could use your review still by the way) because it was really confusing. If they aren't expected to work and people should ignore them, then they should be disabled.

Another step in this direction would be use use the repository settings to require a PR workflow that includes specific checks that must pass in order to merge.

[khaledhosny]

They are expected to work, but they broke recently and no one was able to debug it (@dscorbett couldn’t reproduce locally), so I’m disabling them as a last resort.

[behdad]

Hold on.

[simoncozens]

Yeah, I'm currently debugging this.

[simoncozens]

I've got it building on an Azure instance and can reproduce the problem. hb-shape is dying in the dagger in find_syllables_use. In particular, it's this line:

    | hb_filter (not_standard_default_ignorable, hb_second)

A debugging printf I added in a filter before that gets executed, one in the next hb_filter does not. So it's crashing in not_standard_default_ignorable for some reason.

[simoncozens]

Yeah, confirmed that if I comment out that line it goes through.

[behdad]

For context, this was introduced in #1695

It's my understanding that we are hitting an MSVC compiler bug, also described in: #2293

I'll look into it again and then ask publicly for help working around it.

[behdad]

But yes, this cannot go into a release.

[khaledhosny]

Closing this then, though I still don’t like the fact that all our changes have failing CI builds.

[behdad]

Reopening this to track and fix the corruption / compiler issue.

[behdad]

I though I reopened, and the reopen button is inactive for me now, but still says closed. Weird.

[jfkthame]

Does reopen not work once the branch has been deleted, maybe?

[alerque]

You can't re-open PR's when the source branch with commits either doesn't exist or has been changed so that the latest commit is the same as the proposed merge target.

I don't think this PR would be the right place to track the fix anyway. If the fix is going to be different that disabling the CI job, then just a regular issue stating the problem would be a better tracking point. Then whatever mechanics end up in a PR can take care of it but the issue is tracking the problem not a potential solution.