Respect orderable constraint in ArgumentTypeFuzzer

[duanmeng]

PR #6906 added support to restricting arguments as orderable.

This PR changes ArgumentTypeFuzzer to respect this constraint.

Part of #6718

[netlify]

✅ Deploy Preview for meta-velox canceled.

Name	Link
🔨 Latest commit	97da0e8
🔍 Latest deploy log	https://app.netlify.com/sites/meta-velox/deploys/652777b220ab8c000846f5a6

[mbasmanova]

@duanmeng Looks good. Some comments below.

[duanmeng]

@mbasmanova Hi Masha, I've resolved all the comments and kept this focus on having fuzzer respect 'orderable' property in function. Could you please help to take a look? Thanks a lot.

[mbasmanova]

Thanks.

[facebook-github-bot]

@mbasmanova has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[facebook-github-bot]

@mbasmanova merged this pull request in 30e1854.

[conbench-facebook]

Conbench analyzed the 1 benchmark run on commit 30e1854d.

There was 1 benchmark result indicating a performance regression:

• Commit Run on GitHub-runner-8-core at 2023-10-12 14:53:14Z
  • eq (C++) with source=cpp-micro, suite=velox_benchmark_basic_comparison_conjunct

The full Conbench report has more details.

[mbasmanova]

CC: @assignUser Looks like false positive from Conbench.

[mbasmanova]

CC: @kgpai @pedroerp

[austin3dickey]

Looks like false positive from Conbench.

Yeah, I agree this is post-merge check is probably a false positive, since the pre-merge check passed.

Some background: When we run benchmarks on PR HEAD commits in this repo, we make sure to retry any slower benchmarks 5 times to reduce the chance of a false positive (so PRs aren't blocked). But we don't do retries on merge-commits, for a few reasons:

• benchmarks were already run on the PR HEAD before merging, and they (probably) passed
• cost

Instead, merge-commits run each microbenchmark just once. So they might be slightly more likely to have a false positive.

Why run benchmarks and alert on merge-commits at all? We've seen in the past that sometimes the facebook-github-bot misses PR signals and will merge a PR anyway. If that happened on a PR that actually introduced a regression, we'd rather be notified about it on the PR sooner. So it's probably worth the occasional false positive comment for confirmation.