Consider using macro to generate ParsedSpans boilerplate

[coderabbitai]

Issue Description

Consider using a macro to generate the repetitive fields, setters, getters, and builder logic for ParsedSpans and its builder.

Consider collapsing all of the repetitive fields, setters, getters and the build/validation logic into one macro_rules! instead of hand‐writing each.

Location

src/parser/cst_builder/spans.rs:17

Code Context

/// are sorted and non-overlapping in debug builds.
#[non_exhaustive]
#[derive(Debug, Default, Clone, PartialEq)]
pub struct ParsedSpans {
    /// `import` statement spans.
    imports: Vec<Span>,

Suggested Implementation

macro_rules! define_parsed_spans {
    ( $( $field:ident ),* $(,)? ) => {
        #[derive(Debug, Default, Clone, PartialEq)]
        pub struct ParsedSpans {
            $( pub(crate) $field: Vec<Span> ),*
        }

        #[derive(Default)]
        pub struct ParsedSpansBuilder {
            $( $field: Vec<Span> ),*
        }

        impl ParsedSpansBuilder {
            $(
                #[must_use]
                pub fn $field(mut self, spans: Vec<Span>) -> Self {
                    self.$field = spans;
                    self
                }
            )*

            #[must_use]
            pub fn build(self) -> ParsedSpans {
                let Self { $( $field ),* } = self;
                let result = validate_span_lists_sorted(&[
                    $( (stringify!($field), &$field) ),*
                ]);
                debug_assert!(result.is_ok(), "{}", result.err().unwrap_or_default());

                ParsedSpans { $( $field ),* }
            }
        }

        impl ParsedSpans {
            #[must_use]
            pub fn builder() -> ParsedSpansBuilder {
                ParsedSpansBuilder::default()
            }

            $(
                #[must_use]
                pub fn $field(&self) -> &[Span] {
                    &self.$field
                }
            )*
        }
    }
}

define_parsed_spans!(
    imports,
    typedefs,
    relations,
    indexes,
    functions,
    transformers,
    rules,
);

Benefits

This preserves your build/validation logic verbatim but removes all of the near-duplicate setter/getter boilerplate.

References

• PR: Refactor CST construction into module #79
• Comment: Refactor CST construction into module #79 (comment)

[leynos]

@coderabbitai looking at the codebase, is this issue still relevant? If the issue has been fixed in the code, does the documentation reflect this?

If it is still relevant, please provide an assessment of the issue criticality (critical, high, medium or low), based on risk of the issue impacting the user and the anticipated blast radius.\n\nOnce a decision has been made, apply the appropriate label.

If the issue is documentation ONLY (i.e., no code changes needed), apply the documentation label in addition to the appropriate criticality label.

Please also provide an impact of the required changes.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch issue #87 details
gh issue view 87 --json title,body,labels,state

Length of output: 2542

---

🏁 Script executed:

#!/bin/bash
# Check if the file exists and examine its current state
cat src/parser/cst_builder/spans.rs

Length of output: 8293

---

🏁 Script executed:

#!/bin/bash
# Check for documentation files that might mention ParsedSpans or CST builder patterns
fd -t f 'README|CONTRIBUTING|ARCHITECTURE|DESIGN|docs' | head -20

# Check if there's any documentation about the spans module
rg -i 'ParsedSpans|cst_builder' -g '*.md' -C 2

Length of output: 280

---

🏁 Script executed:

#!/bin/bash
# Apply the "low" criticality label to issue #87
gh issue edit 87 --add-label "low"

Length of output: 42

---

@leynos, I've completed the assessment of issue #87. Here are my findings:

Relevance: ✅ STILL RELEVANT

The repetitive boilerplate pattern described in the issue still exists in src/parser/cst_builder/spans.rs. In fact, the code has grown since the issue was filed—there are now 8 fields (expressions was added) instead of the original 7, making the refactoring even more valuable.

The current implementation contains approximately 150 lines of repetitive code for:

• Field declarations in ParsedSpans and ParsedSpansBuilder
• 8 setter methods in the builder
• 8 getter methods in ParsedSpans
• Manual destructuring and validation in the build() method

Documentation Status: ✅ No updates needed

The documentation doesn't reference this internal implementation detail, so no documentation changes would be required regardless of whether the refactoring is implemented.

Criticality Assessment: 🟢 LOW

Rationale:

• User impact: None—this is an internal code quality improvement with no user-facing changes
• Blast radius: Low—changes are localized to a single file (src/parser/cst_builder/spans.rs)
• Risk: Low—a well-tested macro would generate functionally identical code
• Type: Technical debt/code maintenance, not a bug or missing feature

Impact of Required Changes

Benefits:

• Reduce boilerplate from ~150 lines to ~50 lines
• Make adding new span types trivial (one identifier in the macro invocation)
• Eliminate risk of inconsistency between field implementations
• Improve long-term maintainability

Scope:

• Single file modification
• Existing tests should validate that behaviour is preserved
• No API changes (generated code would be identical)

Label Applied

I've applied the low criticality label to the issue.