chore: don't print warning if fp16 kernel not build

[Xuanwo]

This PR will suppress the warning for fp16 kernel not being built

I personally think this warning isn't helpful, maybe we can just remove it?

---

This PR was primarily authored with Codex using GPT-5-Codex and then hand-reviewed by me. I AM responsible for every change made in this PR. I aimed to keep it aligned with our goals, though I may have missed minor issues. Please flag anything that feels off, I'll fix it quickly.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid early return that drops AVX-512 dist_table build

Lines 18-20 make the build script exit whenever the fp16kernels feature is disabled, but the AVX-512 distance-table kernels and the kernel_support="avx512" cfg are needed even without that feature. With this early return, the AVX-512 C dist_table code is never compiled and the cfg is never emitted, so on x86_64 CPUs that report AVX-512 (see sum_4bit_dist_table in rust/lance-linalg/src/simd/dist_table.rs:37-60) the AVX-512 match arm is compiled out and those CPUs fall all the way back to the scalar path. In the previous revision the script still built dist_table and set the cfg when the feature was off, so this change introduces a significant performance regression on AVX-512 hardware whenever fp16kernels is not enabled (the default build).

Useful? React with 👍 / 👎.

[westonpace]

I personally think this warning isn't helpful, maybe we can just remove it?

The purpose of the warning is to ensure that our production builds (which we deploy to real world workloads) have the correct features enabled.

Perhaps a better way to solve this same problem would be to add a features method which, at runtime, tells which features were compiled into the binary. This could then be used in a CI or pre/post-deploy smoke test of some kind to ensure that we are running builds in production that have all features builtin?

[Xuanwo]

Perhaps a better way to solve this same problem would be to add a features method which, at runtime, tells which features were compiled into the binary.

Seems nice to me. Are you expecting to add this features method and include a dedicated test for it in the smoke tests?

[codecov]

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
rust/lance/src/lib.rs	0.00%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!