crates/biome_analyze/src/rule.rs (1)

97-102: Please lock RuleSource ordering down with a regression test.

The proc-macro unit tests prove the generator, but they do not pin the actual RuleSource ordering that Ord and cmp_any() depend on. A tiny sort/comparison test here would catch accidental enum reshuffles before they reshuffle behaviour.

As per coding guidelines "All code changes MUST include appropriate tests".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_analyze/src/rule.rs` around lines 97 - 102, Add a regression
test that pins the ordering of the RuleSource enum by asserting the expected
ordering behavior used by Ord and cmp_any(); specifically, write a unit test
that enumerates the RuleSource variants in their declared order and asserts
pairwise comparisons (e.g., VariantA < VariantB) and that sorting a vec of all
variants yields the declared order, and also verify cmp_any() produces the same
ordering decisions; place the test adjacent to the RuleSource definition (in the
same module's tests) and reference the RuleSource type and the cmp_any() helper
to make it obvious if the enum order changes.

crates/biome_analyze_macros/src/lib.rs (1)

32-35: Add rustdoc for the new derive.

RuleSourceVariantIndex is now part of this crate’s public surface, but it is undocumented whilst declare_group_from_fs is. A short note about declaration-order indexing would make it much easier to reuse safely.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_analyze_macros/src/lib.rs` around lines 32 - 35, Add a rustdoc
comment for the new derive to document its public API and behavior: above the
proc_macro_derive attribute for rule_source_variant_index, add a short docstring
that explains what RuleSourceVariantIndex does, that it derives an index based
on declaration-order of RuleSource variants, and any caveats about relying on
declaration-order indexing; reference the proc-macro entry point function
rule_source_variant_index (and/or the implementation
rule_source_variant_index::rule_source_variant_index_impl) so users know where
the derive is implemented.

crates/biome_analyze_macros/src/rule_source_variant_index.rs (1)

22-27: Cover the variant-limit guard too.

The non-enum path is tested, but the u16::MAX + 1 guard is still freewheeling. A generated mega-enum in this module would pin that compile-time error down as well.

As per coding guidelines "All code changes MUST include appropriate tests".

Also applies to: 58-105

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_analyze_macros/src/rule_source_variant_index.rs` around lines 22
- 27, Add a unit test that exercises the enum-variant-limit guard: construct a
synthetic syn::DeriveInput with Data::Enum whose variants vec length equals
usize::from(u16::MAX) + 1 (you can build a DataEnum and push dummy Variant
entries rather than writing 65k tokens) and call the same function/path that
contains the guard (the code referencing data_enum, input.ident and returning
the syn::Error with message "RuleSourceVariantIndex supports at most u16::MAX +
1 variants"); assert it returns Err and that the error message contains that
string. Also add a complementary test for the non-enum path if absent. This
ensures the guard in rule_source_variant_index.rs is covered without generating
an enormous real enum.