[cxx-interop][test][android] Disable FRT sequence tests on Android armv7

[j-hui]

These tests depend on std::vector<FRT*> conforming to CxxRandomAccessCollection, which isn't kicking in for some reason.

Supersedes #90323 (disables some additional tests)

[j-hui]

@swift-ci test android

[finagolfin]

This passes and the previous one isn't run, as we don't run the executable tests on Android yet, so remove these two and we'll get this in. No need to run Android tests on this again, as #90343 has it failing earlier.

[j-hui]

Sure, will do!

Do you reckon it's worth leaving a comment on the executable test, eg "NB this will fail on android due to a missing conformance"?

[finagolfin]

No, don't worry, there are a couple dozen executable tests failing on Android AArch64 currently, likely more on 32-bit armv7, which I haven't run those for in years.

Once we get the executable tests running on CI this summer, I will go through those and see what to do.

[j-hui]

@swift-ci please smoke test

[finagolfin]

@swift-ci smoke test windows

[j-hui]

The same lldb tests seem to have failed:

********************
Failed Tests (18):
  lldb-api :: lang/swift/async/actors/unprioritised_jobs/TestSwiftActorUnprioritisedJobs.py
  lldb-api :: lang/swift/async/continuations/TestSwiftContinuationSynthetic.py
  lldb-api :: lang/swift/async/expr/TestSwiftAsyncExpressions.py
  lldb-api :: lang/swift/async/formatters/task/TestSwiftTaskSyntheticProvider.py
  lldb-api :: lang/swift/async/formatters/task/complete/TestSwiftTaskComplete.py
  lldb-api :: lang/swift/async/formatters/task/suspended/TestSwiftTaskSuspended.py
  lldb-api :: lang/swift/async/formatters/taskpriority/TestSwiftTaskPrioritySummary.py
  lldb-api :: lang/swift/async/taskgroups/TestSwiftTaskGroupSynthetic.py
  lldb-api :: lang/swift/closures_var_not_captured/TestSwiftClosureVarNotCaptured.py
  lldb-api :: lang/swift/expression/actor/TestSwiftExpressionActor.py
  lldb-api :: lang/swift/foundation_value_types/data/TestSwiftFoundationTypeData.py
  lldb-api :: lang/swift/foundation_value_types/date/TestSwiftFoundationTypeDate.py
  lldb-api :: lang/swift/foundation_value_types/uuid/TestSwiftFoundationTypeUUID.py
  lldb-api :: lang/swift/observation/TestSwiftObservation.py
  lldb-api :: lang/swift/po/recursive/TestSwiftPORecursiveBehavior.py
  lldb-api :: lang/swift/po/ref_types/TestSwiftPORefTypes.py
  lldb-api :: lang/swift/po/val_types/TestSwiftPOValTypes.py
  lldb-api :: lang/swift/variables/consume_operator_async/TestSwiftConsumeOperatorAsync.py

I saw there was some discussion on swiftlang/llvm-project#13212 about #90324 not being reflected in the latest PR tests. Maybe we got unlucky again? Will retrigger CI and see if it goes through now.

[j-hui]

@swift-ci smoke test windows

[finagolfin]

I made sure to trigger this last Windows CI run here well after #90324 was merged, so either the CI randomly won't pick up recently merged commits, as I see some other Windows CI runs passing again so they must have got the #90324 fix, or those tests are still flaking after the fix, as they were before when they were disabled weeks ago.

@charles-zablit, you may want to check the Windows PR CI results of several failing runs today, to see if those lldb tests are still flaking after your fix.

[charles-zablit]

What we have seen in the past with @AnthonyLatsis is that the pull request branch is not rebased with the latest commits from the target branch. At least not often.

What ends up happening is that even though the CI is fixed on top of tree, those changes are not on the PR branch (because Github did not update it yet) and the CI fails again. Given that the fix was on the swift repo as well, I think it would be worth rebasing this branch.

[finagolfin]

What ends up happening is that even though the CI is fixed on top of tree, those changes are not on the PR branch (because Github did not update it yet)

I thought that was fixed by #89795?

[finagolfin]

Got the Android CI green again, thanks. 👍

[AnthonyLatsis]

I thought that was fixed by #89795?

We do shallow checkouts on Windows, which my change did not account for. That has already been sorted, but we also need the job script—I genuinely have no idea how many of those we have—to first apply the same logic to the originating PR because update-checkout neither does that nor re-runs itself.

[finagolfin]

OK, well, I don't see a bunch of lldb test flakes on Windows since, so this probably was a source checkout issue. Now that you got #90294 in, hopefully that won't happen again.