Filter the suggestion list by cursor's position

[ehwan]

Based on the cursor's position, it determines if it's inside of reduce action, or production rule line,

and filter out impossible suggestion like %direcitve in production rule or reduce action.

[gemini-code-assist]

Code Review

This pull request refines the LSP autocompletion and hover documentation for RustyLR by introducing context-aware completions. It distinguishes between being inside a production rule line and inside a ReduceAction block, ensuring that directives, keywords, and substitution variables are only suggested where they are syntactically valid. Additionally, hover documentation is added for global $name substitution variables. A critical bug was identified in the completion logic where global substitution variables (such as $tokentype) are incorrectly omitted when the cursor is inside a ReduceAction block because in_rule_line is true; updating the condition to check if the cursor is either outside a rule line or inside a reduce action resolves this issue.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Inside a ReduceAction block, the cursor is technically within a production rule line, so line_variables.in_rule_line is true. However, the user is writing Rust code inside the block and should be offered global substitution variables (like $tokentype, $location, etc.) and terminal/non-terminal substitutions.

With the current condition if !line_variables.in_rule_line, these completions are completely omitted when inside a ReduceAction block, and instead, the else branch incorrectly suggests pattern-only keywords like error and $sep.

Additionally, this bug guarantees that the test completes_dollar_variables will fail:

• If parse_args succeeds, in_rule_line is true, so $tokentype is not suggested, causing assert!(labels.contains("$tokentype")) to fail.
• If parse_args fails, in_reduce_action is false, so $1 is not suggested, causing assert!(labels.contains("$1")) to fail.

Changing the condition to if !line_variables.in_rule_line || line_variables.in_reduce_action resolves this issue and allows both assertions to pass.

Suggested change

	if !line_variables.in_rule_line {
	if !line_variables.in_rule_line || line_variables.in_reduce_action {