reject unsupported logic edge cases during rule loading

[akshat4703]

Description

Add core rule-validation checks to reject logic constructs that the optimized matcher/indexer cannot safely handle.

The following patterns are now rejected during rule loading:

• Top-level not statements
• Nested not statements (e.g. not: not: ...)
• Top-level count(...): 0 statements

These constructs can cause ambiguity or incorrect behavior in the optimized rule matcher and indexer. Rejecting them at load time ensures rules remain compatible with the matcher’s assumptions and prevents subtle evaluation issues.

---

Implementation Details

• Introduced Rule._lint_logic_edge_cases() in __init__.py.
• Invoked the check from Rule.from_dict() after rule statement construction.
• Updated the RuleSet.match() docstring to document that these constructs are now rejected during rule loading.
• Added regression tests in test_rules.py covering:
  • invalid_top_level_not_statement
  • invalid_nested_not_statement
  • invalid_top_level_count_zero_statement

---

Validation

Executed targeted tests for the new validation logic:

venv/bin/python -m pytest -q tests/test_rules.py -k "invalid_top_level_not_statement or invalid_nested_not_statement or invalid_top_level_count_zero_statement"

Result:

3 passed

[x] No CHANGELOG update needed

[github-actions]

Please add bug fixes, new features, breaking changes and anything else you think is worthwhile mentioning to the master (unreleased) section of CHANGELOG.md. If no CHANGELOG update is needed add the following to the PR description: [x] No CHANGELOG update needed

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the rule loading process by implementing strict validation for specific logic constructs. By rejecting problematic rule patterns at an early stage, it ensures that all loaded rules are compatible with the optimized matcher and indexer, thereby preventing potential ambiguities and incorrect behavior during rule evaluation. This change improves the robustness and reliability of the rule engine.

Highlights

• Rule Validation: Introduced core rule-validation checks to reject logic constructs that the optimized matcher/indexer cannot safely handle.
• Unsupported Patterns: Rules containing top-level not statements, nested not statements (e.g., not: not: ...), or top-level count(...): 0 statements are now rejected during rule loading.
• Implementation: A new static method _lint_logic_edge_cases was added to Rule and integrated into Rule.from_dict() to perform these checks.
• Documentation and Testing: The RuleSet.match() docstring was updated, and regression tests were added to cover the newly rejected patterns.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• capa/rules/init.py
  • Added a new static method _lint_logic_edge_cases to Rule to identify and reject unsupported logic constructs.
  • Integrated the _lint_logic_edge_cases method into Rule.from_dict() to perform validation during rule instantiation.
  • Updated the docstring for RuleSet.match() to reflect that certain logic edge cases are now rejected during rule loading.
• tests/test_rules.py
  • Added test_invalid_top_level_not_statement to verify rejection of top-level not statements.
  • Added test_invalid_nested_not_statement to verify rejection of nested not statements.
  • Added test_invalid_top_level_count_zero_statement to verify rejection of top-level count(...): 0 statements.

Activity

• The author introduced a new static method _lint_logic_edge_cases in capa/rules/__init__.py to validate rule statements.
• The from_dict method in capa/rules/__init__.py was modified to invoke this new linting function after constructing a rule statement.
• The docstring for the match method in capa/rules/__init__.py was updated to document the newly rejected rule constructs.
• New regression tests were added in tests/test_rules.py to specifically test the rejection of invalid top-level not statements, nested not statements, and top-level count(...): 0 statements.
• Validation was performed by executing targeted pytest commands, confirming that all 3 new tests passed as expected.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces validation to reject unsupported logic constructs during rule loading, specifically top-level not statements, nested not statements, and top-level count(...): 0 statements. The implementation adds a _lint_logic_edge_cases method that recursively checks rule statements. The changes are well-implemented and include corresponding tests and documentation updates. I have one suggestion to improve the readability of the new validation logic.

[gemini-code-assist]

For better readability and to more clearly separate the concerns of checking root-level statements versus nested statements, you could refactor this logic. Grouping all is_root checks together at the beginning makes the function's logic easier to follow.

Suggested change

	if isinstance(statement, ceng.Not):
	if is_root:
	raise InvalidRule("top level statement may not be a `not` statement")
	if isinstance(statement.child, ceng.Not):
	raise InvalidRule("nested `not` statements are not supported")
	if is_root and isinstance(statement, ceng.Range) and statement.min == 0 and statement.max == 0:
	raise InvalidRule("top level statement may not be `count(...): 0`")
	if is_root:
	if isinstance(statement, ceng.Not):
	raise InvalidRule("top level statement may not be a `not` statement")
	if isinstance(statement, ceng.Range) and statement.min == 0 and statement.max == 0:
	raise InvalidRule("top level statement may not be `count(...): 0`")
	if isinstance(statement, ceng.Not) and isinstance(statement.child, ceng.Not):
	raise InvalidRule("nested `not` statements are not supported")

CHANGELOG updated or no update needed, thanks! 😄

[williballenthin]

These constructs can cause ambiguity or incorrect behavior in the optimized rule matcher and indexer

this is an issue with the optimized matcher, not the underlying rules, so i don't want to tell users they did something wrong.

perhaps we should fall back to the unoptimized matcher in these cases.

[williballenthin]

@akshat4703 please open issues with feature requests or bug reports so we can discuss ideas before you open PRs.

[akshat4703]

@akshat4703 please open issues with feature requests or bug reports so we can discuss ideas before you open PRs.

ok will keep this feedback for future

[akshat4703]

These constructs can cause ambiguity or incorrect behavior in the optimized rule matcher and indexer

this is an issue with the optimized matcher, not the underlying rules, so i don't want to tell users they did something wrong.

perhaps we should fall back to the unoptimized matcher in these cases.

Good callout. I updated the implementation to avoid rejecting these patterns or attributing the limitation to rule authors.

Instead of failing at load time, rules that cannot produce a safe index selector (rec(...) returns None) are treated as non-indexable and transparently evaluated using the unoptimized matcher. Optimized matching still applies to the rest of the ruleset.

Changes

• Added a fallback_rules bucket in the per-scope feature index.
• Rules that cannot be safely indexed are placed in fallback_rules.
• _match() now seeds candidates with fallback_rules to ensure correct evaluation.

Tests

• Removed previous xfails.
• Added/updated tests for:
  • top-level not
  • nested not
  • top-level count(...): 0

These confirm correct behavior while preserving optimized matching for other rules.