Skip to content

feat: deepen dialect system — dialect-aware parsing (#323)#336

Merged
ajitpratap0 merged 5 commits intomainfrom
feat/dialect-deepening
Feb 25, 2026
Merged

feat: deepen dialect system — dialect-aware parsing (#323)#336
ajitpratap0 merged 5 commits intomainfrom
feat/dialect-deepening

Conversation

@ajitpratap0
Copy link
Copy Markdown
Owner

Closes #323

Summary

Deepens the dialect system so that dialect-specific syntax is actively gated at parse time, rather than merely having keyword lists.

Changes

pkg/sql/keywords/dialect.go

  • Oracle keyword list (ORACLE_SPECIFIC) added — previously DialectKeywords(DialectOracle) returned nil.
  • IsValidDialect(name string) bool helper — returns true for any known dialect name or empty string; used to reject unknown names at both CLI and parser levels.

pkg/sql/parser/select.go

  • Reject LIMIT in SQL Server mode — fires an error pointing to TOP / OFFSET...FETCH NEXT alternatives.
  • Reject TOP in MySQL/PostgreSQL mode — fires an error pointing to LIMIT/OFFSET.

pkg/sql/parser/expressions.go

  • Reject ILIKE in non-PostgreSQL dialects — fires an error suggesting LIKE or LOWER().

pkg/sql/parser/validate.go

  • ValidateBytesWithDialect and ParseBytesWithDialect now return an error for unknown dialect names.
  • Added validDialectList() helper for human-readable error messages.

cmd/gosqlx/cmd/validate.go

  • CLI validates --dialect flag early (before any parsing) using keywords.IsValidDialect.

pkg/sql/parser/dialect_test.go

  • 15 new tests covering all dialect gates and the Oracle keyword list.
  • Tests confirm valid syntax still parses in its correct dialect (no regressions).

@claude
Copy link
Copy Markdown

claude bot commented Feb 25, 2026

Claude finished @ajitpratap0's task —— View job


PR Review: Dialect System Deepening

Reviewing the dialect system enhancements that add parse-time dialect validation.

Todo List

  • Read repository guidelines (CLAUDE.md)
  • Analyze all 6 modified files
  • Review code quality and architecture
  • Check for bugs and potential issues
  • Evaluate performance considerations
  • Review security aspects
  • Assess test coverage
  • Provide comprehensive feedback

✅ Overall Assessment

This is a well-implemented feature that successfully adds dialect-aware parsing restrictions to GoSQLX. The changes are clean, well-tested, and maintain backward compatibility while adding meaningful functionality.

🎯 Strengths

Excellent Architecture & Design

  • Clean separation of concerns: Dialect validation is properly separated between keywords, parser, and CLI layers
  • Consistent error handling: All dialect gates provide helpful error messages with alternative suggestions
  • Backward compatibility: Existing APIs remain unchanged; new functionality is additive
  • Performance-conscious: Early validation prevents unnecessary parsing work

Robust Implementation

  • Early validation: CLI validates dialect flags before any parsing (pkg/sql/parser/validate.go:164-167, cmd/gosqlx/cmd/validate.go:80-82)
  • Comprehensive Oracle support: Finally implements ORACLE_SPECIFIC keyword list with 56+ keywords (pkg/sql/keywords/dialect.go:267-323)
  • Smart dialect gates: Only enforces restrictions when dialect is explicitly set, maintaining default behavior
  • Helpful error messages: All errors suggest appropriate alternatives (e.g., "use LIMIT/OFFSET" instead of TOP)

Excellent Test Coverage

  • 15 comprehensive tests covering all dialect gates and Oracle keyword list
  • Both positive and negative cases: Tests both valid syntax in correct dialects and rejection in wrong dialects
  • Edge case coverage: Tests unknown dialects, default behavior, and backward compatibility
  • Practical examples: Real-world SQL examples in tests

🔧 Code Quality Highlights

Smart Implementation Patterns

// pkg/sql/parser/expressions.go:171-178
// Only enforces ILIKE restriction when dialect is explicitly set
if strings.EqualFold(operator, "ILIKE") &&
    p.dialect != "" &&  // Key insight: empty dialect bypasses restriction
    p.dialect != string(keywords.DialectPostgreSQL) {

User-Friendly Error Messages

// pkg/sql/parser/select.go:1057-1060  
return fmt.Errorf(
    "LIMIT clause is not supported in SQL Server; use TOP or OFFSET/FETCH NEXT instead",
)

Efficient Helper Functions

// pkg/sql/keywords/dialect.go:102-112
func IsValidDialect(name string) bool {
    if name == "" { return true }  // Smart default handling
    for _, d := range AllDialects() {
        if string(d) == name { return true }
    }
    return false
}

⚠️ Minor Areas for Improvement

1. String Comparison Efficiency (Low Priority)

Location: pkg/sql/parser/expressions.go:171

// Current: Case-insensitive comparison every time
if strings.EqualFold(operator, "ILIKE") &&

// Consider: Pre-normalize during tokenization or use constant

Impact: Minimal - this is not a hot path

2. Potential Case Sensitivity Issue (Low Priority)

Location: pkg/sql/parser/select.go:487

// Uses string literal comparison instead of token type
if strings.ToUpper(p.currentToken.Literal) == "TOP"

Suggestion: Consider using token type constants for consistency with the rest of the codebase

3. Test Helper Documentation (Very Low Priority)

Location: pkg/sql/parser/dialect_test.go:369
The containsAny helper function could benefit from a brief comment explaining its case-insensitive matching behavior.

🚀 Performance Considerations

  • Early validation: Dialect validation happens before parsing, saving CPU cycles
  • Zero allocations: String comparisons and dialect checks are efficient
  • No regression risk: Changes only add new validation paths; existing fast paths unchanged
  • Memory efficient: Oracle keyword list is pre-allocated and reused

🔒 Security Assessment

  • No security concerns identified
  • Input validation: All dialect names are validated against a whitelist
  • Error handling: No sensitive information leaked in error messages
  • Safe defaults: Unknown dialects are rejected rather than assumed valid

📊 Test Coverage Analysis

The test suite is comprehensive with 15 tests covering:

  • ✅ All three dialect gates (LIMIT, TOP, ILIKE)
  • ✅ Both positive and negative test cases
  • ✅ Oracle keyword list validation
  • ✅ Unknown dialect rejection
  • ✅ Backward compatibility scenarios
  • ✅ Default behavior preservation

Test Quality: High - uses realistic SQL examples and proper error assertion patterns following project conventions.

🎯 Recommendations

Immediate Actions (None Required)

This PR is ready for merge as-is. The minor improvements mentioned above can be addressed in future iterations if desired.

Future Enhancements (Optional)

  1. Performance optimization: Consider pre-normalizing operator strings during tokenization
  2. Enhanced error context: Could include position information in dialect error messages
  3. CLI improvement: Could add --list-dialects flag to show supported dialects

📈 Impact Assessment

  • ✅ Backward Compatibility: Fully maintained
  • ✅ Performance: No negative impact, potential positive impact from early validation
  • ✅ User Experience: Significantly improved with helpful error messages
  • ✅ Code Maintainability: Clean, well-organized implementation
  • ✅ Test Reliability: Comprehensive test coverage ensures stability

🎉 Conclusion

This is an exemplary implementation that demonstrates strong understanding of the codebase architecture and Go best practices. The dialect system deepening successfully adds valuable functionality while maintaining the high quality standards of the GoSQLX project.

Recommendation: ✅ Approve and merge


@claude
Copy link
Copy Markdown

claude bot commented Feb 25, 2026

Claude finished @ajitpratap0's task —— View job



PR Review: Dialect System Deepening

Reviewing the dialect system enhancements that add parse-time dialect validation.

Todo List

  • Read repository guidelines (CLAUDE.md)
  • Analyze all 6 modified files
  • Review code quality and architecture
  • Check for bugs and potential issues
  • Evaluate performance considerations
  • Review security aspects
  • Assess test coverage
  • Provide comprehensive feedback

✅ Overall Assessment

This is a well-implemented feature that successfully adds dialect-aware parsing restrictions to GoSQLX. The changes are clean, well-tested, and maintain backward compatibility while adding meaningful functionality.

🎯 Strengths

Excellent Architecture & Design

  • Clean separation of concerns: Dialect validation is properly separated between keywords, parser, and CLI layers
  • Consistent error handling: All dialect gates provide helpful error messages with alternative suggestions
  • Backward compatibility: Existing APIs remain unchanged; new functionality is additive
  • Performance-conscious: Early validation prevents unnecessary parsing work

Robust Implementation

  • Early validation: CLI validates dialect flags before any parsing (pkg/sql/parser/validate.go:166-169, cmd/gosqlx/cmd/validate.go:80-82)
  • Comprehensive Oracle support: Finally implements ORACLE_SPECIFIC keyword list with 56+ keywords (pkg/sql/keywords/dialect.go:267-323)
  • Smart dialect gates: Only enforces restrictions when dialect is explicitly set, maintaining default behavior
  • Helpful error messages: All errors suggest appropriate alternatives (e.g., "use LIMIT/OFFSET" instead of TOP)

Excellent Test Coverage

  • 15 comprehensive tests covering all dialect gates and Oracle keyword list
  • Both positive and negative cases: Tests both valid syntax in correct dialects and rejection in wrong dialects
  • Edge case coverage: Tests unknown dialects, default behavior, and backward compatibility
  • Practical examples: Real-world SQL examples in tests

🔧 Code Quality Highlights

Smart Implementation Patterns

// pkg/sql/parser/expressions.go:171-173
// Only enforces ILIKE restriction when dialect is explicitly set
if strings.EqualFold(operator, "ILIKE") &&
    p.dialect != "" &&  // Key insight: empty dialect bypasses restriction
    p.dialect != string(keywords.DialectPostgreSQL) {

User-Friendly Error Messages

// pkg/sql/parser/select.go:1060-1064  
msg := "LIMIT clause is not supported in SQL Server; use TOP or OFFSET/FETCH NEXT instead"
if p.dialect == string(keywords.DialectOracle) {
    msg = "LIMIT clause is not supported in Oracle; use ROWNUM or FETCH FIRST … ROWS ONLY instead"
}

Efficient Helper Functions

// pkg/sql/keywords/dialect.go:102-112
func IsValidDialect(name string) bool {
    if name == "" { return true }  // Smart default handling
    for _, d := range AllDialects() {
        if string(d) == name { return true }
    }
    return false
}

⚠️ Minor Areas for Improvement

1. String Comparison Efficiency (Low Priority)

Location: pkg/sql/parser/expressions.go:171

// Current: Case-insensitive comparison every time
if strings.EqualFold(operator, "ILIKE") &&

// Consider: Pre-normalize during tokenization or use constant

Impact: Minimal - this is not a hot path

2. Potential Case Sensitivity Issue (Low Priority)

Location: pkg/sql/parser/select.go:492

// Uses string literal comparison instead of token type
if strings.ToUpper(p.currentToken.Literal) == "TOP"

Suggestion: Consider using token type constants for consistency with the rest of the codebase

3. Test Helper Documentation (Very Low Priority)

Location: pkg/sql/parser/dialect_test.go:407
The containsAny helper function could benefit from a brief comment explaining its case-insensitive matching behavior.

🚀 Performance Considerations

  • Early validation: Dialect validation happens before parsing, saving CPU cycles
  • Zero allocations: String comparisons and dialect checks are efficient
  • No regression risk: Changes only add new validation paths; existing fast paths unchanged
  • Memory efficient: Oracle keyword list is pre-allocated and reused

🔒 Security Assessment

  • No security concerns identified
  • Input validation: All dialect names are validated against a whitelist
  • Error handling: No sensitive information leaked in error messages
  • Safe defaults: Unknown dialects are rejected rather than assumed valid

📊 Test Coverage Analysis

The test suite is comprehensive with 15 tests covering:

  • ✅ All three dialect gates (LIMIT, TOP, ILIKE)
  • ✅ Both positive and negative test cases
  • ✅ Oracle keyword list validation
  • ✅ Unknown dialect rejection
  • ✅ Backward compatibility scenarios
  • ✅ Default behavior preservation

Test Quality: High - uses realistic SQL examples and proper error assertion patterns following project conventions.

🎯 Recommendations

Immediate Actions (None Required)

This PR is ready for merge as-is. The minor improvements mentioned above can be addressed in future iterations if desired.

Future Enhancements (Optional)

  1. Performance optimization: Consider pre-normalizing operator strings during tokenization
  2. Enhanced error context: Could include position information in dialect error messages
  3. CLI improvement: Could add --list-dialects flag to show supported dialects

📈 Impact Assessment

  • ✅ Backward Compatibility: Fully maintained
  • ✅ Performance: No negative impact, potential positive impact from early validation
  • ✅ User Experience: Significantly improved with helpful error messages
  • ✅ Code Maintainability: Clean, well-organized implementation
  • ✅ Test Reliability: Comprehensive test coverage ensures stability

🎉 Conclusion

This is an exemplary implementation that demonstrates strong understanding of the codebase architecture and Go best practices. The dialect system deepening successfully adds valuable functionality while maintaining the high quality standards of the GoSQLX project.

Recommendation: ✅ Approve and merge


@ajitpratap0 ajitpratap0 force-pushed the feat/dialect-deepening branch from cdc4850 to 8b836f0 Compare February 25, 2026 01:34
@claude
Copy link
Copy Markdown

claude bot commented Feb 25, 2026

Claude finished @ajitpratap0's task —— View job


PR Review: Dialect System Deepening

Reviewing the dialect system enhancements that add parse-time dialect validation.

Todo List

  • Read repository guidelines (CLAUDE.md)
  • Analyze all 8 modified files
  • Review code quality and architecture
  • Check for bugs and potential issues
  • Evaluate performance considerations
  • Review security aspects
  • Assess test coverage
  • Provide comprehensive feedback

✅ Overall Assessment

This is a well-implemented feature that successfully adds dialect-aware parsing restrictions to GoSQLX. The changes are clean, well-tested, and maintain backward compatibility while adding meaningful functionality.

🎯 Strengths

Excellent Architecture & Design

  • Clean separation of concerns: Dialect validation is properly separated between keywords, parser, and CLI layers
  • Consistent error handling: All dialect gates provide helpful error messages with alternative suggestions
  • Backward compatibility: Existing APIs remain unchanged; new functionality is additive
  • Performance-conscious: Early validation prevents unnecessary parsing work

Robust Implementation

  • Early validation: CLI validates dialect flags before any parsing (pkg/sql/parser/validate.go:166-169, cmd/gosqlx/cmd/validate.go:80-82)
  • Comprehensive Oracle support: Finally implements ORACLE_SPECIFIC keyword list with 56+ keywords (pkg/sql/keywords/dialect.go:267-318)
  • Smart dialect gates: Only enforces restrictions when dialect is explicitly set, maintaining default behavior
  • Helpful error messages: All errors suggest appropriate alternatives (e.g., "use LIMIT/OFFSET" instead of TOP)

Excellent Test Coverage

  • 15 comprehensive tests covering all dialect gates and Oracle keyword list
  • Both positive and negative cases: Tests both valid syntax in correct dialects and rejection in wrong dialects
  • Edge case coverage: Tests unknown dialects, default behavior, and backward compatibility
  • Practical examples: Real-world SQL examples in tests

🔧 Code Quality Highlights

Smart Implementation Patterns

// pkg/sql/parser/expressions.go:171-173
// Only enforces ILIKE restriction when dialect is explicitly set
if strings.EqualFold(operator, "ILIKE") &&
    p.dialect != "" &&  // Key insight: empty dialect bypasses restriction
    p.dialect != string(keywords.DialectPostgreSQL) {

User-Friendly Error Messages

// pkg/sql/parser/select.go:1120-1124  
msg := "LIMIT clause is not supported in SQL Server; use TOP or OFFSET/FETCH NEXT instead"
if p.dialect == string(keywords.DialectOracle) {
    msg = "LIMIT clause is not supported in Oracle; use ROWNUM or FETCH FIRST … ROWS ONLY instead"
}

Efficient Helper Functions

// pkg/sql/keywords/dialect.go:102-112
func IsValidDialect(name string) bool {
    if name == "" { return true }  // Smart default handling
    for _, d := range AllDialects() {
        if string(d) == name { return true }
    }
    return false
}

⚠️ Minor Areas for Improvement

1. String Comparison Efficiency (Low Priority)

Location: pkg/sql/parser/expressions.go:171

// Current: Case-insensitive comparison every time
if strings.EqualFold(operator, "ILIKE") &&

// Consider: Pre-normalize during tokenization or use constant

Impact: Minimal - this is not a hot path

2. Potential Case Sensitivity Issue (Low Priority)

Location: pkg/sql/parser/select.go:453

// Uses string literal comparison instead of token type
if nonTopDialects[p.dialect] && strings.ToUpper(p.currentToken.Literal) == "TOP"

Suggestion: Consider using token type constants for consistency with the rest of the codebase

3. Test Helper Documentation (Very Low Priority)

Location: pkg/sql/parser/dialect_test.go:407
The containsAny helper function could benefit from a brief comment explaining its case-insensitive matching behavior.

🚀 Performance Considerations

  • Early validation: Dialect validation happens before parsing, saving CPU cycles
  • Zero allocations: String comparisons and dialect checks are efficient
  • No regression risk: Changes only add new validation paths; existing fast paths unchanged
  • Memory efficient: Oracle keyword list is pre-allocated and reused

🔒 Security Assessment

  • No security concerns identified
  • Input validation: All dialect names are validated against a whitelist
  • Error handling: No sensitive information leaked in error messages
  • Safe defaults: Unknown dialects are rejected rather than assumed valid

📊 Test Coverage Analysis

The test suite is comprehensive with 15 tests covering:

  • ✅ All three dialect gates (LIMIT, TOP, ILIKE)
  • ✅ Both positive and negative test cases
  • ✅ Oracle keyword list validation
  • ✅ Unknown dialect rejection
  • ✅ Backward compatibility scenarios
  • ✅ Default behavior preservation

Test Quality: High - uses realistic SQL examples and proper error assertion patterns following project conventions.

🎯 Recommendations

Immediate Actions (None Required)

This PR is ready for merge as-is. The minor improvements mentioned above can be addressed in future iterations if desired.

Future Enhancements (Optional)

  1. Performance optimization: Consider pre-normalizing operator strings during tokenization
  2. Enhanced error context: Could include position information in dialect error messages
  3. CLI improvement: Could add --list-dialects flag to show supported dialects

📈 Impact Assessment

  • ✅ Backward Compatibility: Fully maintained
  • ✅ Performance: No negative impact, potential positive impact from early validation
  • ✅ User Experience: Significantly improved with helpful error messages
  • ✅ Code Maintainability: Clean, well-organized implementation
  • ✅ Test Reliability: Comprehensive test coverage ensures stability

🎉 Conclusion

This is an exemplary implementation that demonstrates strong understanding of the codebase architecture and Go best practices. The dialect system deepening successfully adds valuable functionality while maintaining the high quality standards of the GoSQLX project.

Recommendation: ✅ Approve and merge


@claude
Copy link
Copy Markdown

claude bot commented Feb 25, 2026

Claude finished @ajitpratap0's task —— View job


PR Review: Dialect System Deepening

Reviewing the dialect system enhancements that add parse-time dialect validation.

Todo List

  • Read repository guidelines (CLAUDE.md)
  • Analyze all modified files
  • Review code quality and architecture
  • Check for bugs and potential issues
  • Evaluate performance considerations
  • Review security aspects
  • Assess test coverage
  • Provide comprehensive feedback

✅ Overall Assessment

This is a well-implemented feature that successfully adds dialect-aware parsing restrictions to GoSQLX. The changes are clean, well-tested, and maintain backward compatibility while adding meaningful functionality.

🎯 Strengths

Excellent Architecture & Design

  • Clean separation of concerns: Dialect validation is properly separated between keywords, parser, and CLI layers
  • Consistent error handling: All dialect gates provide helpful error messages with alternative suggestions
  • Backward compatibility: Existing APIs remain unchanged; new functionality is additive
  • Performance-conscious: Early validation prevents unnecessary parsing work

Robust Implementation

  • Early validation: CLI validates dialect flags before any parsing (pkg/sql/parser/validate.go:166-169, cmd/gosqlx/cmd/validate.go:80-82)
  • Comprehensive Oracle support: Finally implements ORACLE_SPECIFIC keyword list with 56+ keywords (pkg/sql/keywords/dialect.go:267-318)
  • Smart dialect gates: Only enforces restrictions when dialect is explicitly set, maintaining default behavior
  • Helpful error messages: All errors suggest appropriate alternatives (e.g., "use LIMIT/OFFSET" instead of TOP)

Excellent Test Coverage

  • 15 comprehensive tests covering all dialect gates and Oracle keyword list
  • Both positive and negative cases: Tests both valid syntax in correct dialects and rejection in wrong dialects
  • Edge case coverage: Tests unknown dialects, default behavior, and backward compatibility
  • Practical examples: Real-world SQL examples in tests

🔧 Code Quality Highlights

Smart Implementation Patterns

// pkg/sql/parser/expressions.go:171-173
// Only enforces ILIKE restriction when dialect is explicitly set
if strings.EqualFold(operator, "ILIKE") &&
    p.dialect != "" &&  // Key insight: empty dialect bypasses restriction
    p.dialect != string(keywords.DialectPostgreSQL) {

User-Friendly Error Messages

// pkg/sql/parser/select.go:1120-1124  
msg := "LIMIT clause is not supported in SQL Server; use TOP or OFFSET/FETCH NEXT instead"
if p.dialect == string(keywords.DialectOracle) {
    msg = "LIMIT clause is not supported in Oracle; use ROWNUM or FETCH FIRST … ROWS ONLY instead"
}

Efficient Helper Functions

// pkg/sql/keywords/dialect.go:102-112
func IsValidDialect(name string) bool {
    if name == "" { return true }  // Smart default handling
    for _, d := range AllDialects() {
        if string(d) == name { return true }
    }
    return false
}

⚠️ Minor Areas for Improvement

1. String Comparison Efficiency (Low Priority)

Location: pkg/sql/parser/expressions.go:171

// Current: Case-insensitive comparison every time
if strings.EqualFold(operator, "ILIKE") &&

// Consider: Pre-normalize during tokenization or use constant

Impact: Minimal - this is not a hot path

2. Potential Case Sensitivity Issue (Low Priority)

Location: pkg/sql/parser/select.go:453

// Uses string literal comparison instead of token type
if nonTopDialects[p.dialect] && strings.ToUpper(p.currentToken.Literal) == "TOP"

Suggestion: Consider using token type constants for consistency with the rest of the codebase

3. Test Helper Documentation (Very Low Priority)

Location: pkg/sql/parser/dialect_test.go:407
The containsAny helper function could benefit from a brief comment explaining its case-insensitive matching behavior.

🚀 Performance Considerations

  • Early validation: Dialect validation happens before parsing, saving CPU cycles
  • Zero allocations: String comparisons and dialect checks are efficient
  • No regression risk: Changes only add new validation paths; existing fast paths unchanged
  • Memory efficient: Oracle keyword list is pre-allocated and reused

🔒 Security Assessment

  • No security concerns identified
  • Input validation: All dialect names are validated against a whitelist
  • Error handling: No sensitive information leaked in error messages
  • Safe defaults: Unknown dialects are rejected rather than assumed valid

📊 Test Coverage Analysis

The test suite is comprehensive with 15 tests covering:

  • ✅ All three dialect gates (LIMIT, TOP, ILIKE)
  • ✅ Both positive and negative test cases
  • ✅ Oracle keyword list validation
  • ✅ Unknown dialect rejection
  • ✅ Backward compatibility scenarios
  • ✅ Default behavior preservation

Test Quality: High - uses realistic SQL examples and proper error assertion patterns following project conventions.

🎯 Recommendations

Immediate Actions (None Required)

This PR is ready for merge as-is. The minor improvements mentioned above can be addressed in future iterations if desired.

Future Enhancements (Optional)

  1. Performance optimization: Consider pre-normalizing operator strings during tokenization
  2. Enhanced error context: Could include position information in dialect error messages
  3. CLI improvement: Could add --list-dialects flag to show supported dialects

📈 Impact Assessment

  • ✅ Backward Compatibility: Fully maintained
  • ✅ Performance: No negative impact, potential positive impact from early validation
  • ✅ User Experience: Significantly improved with helpful error messages
  • ✅ Code Maintainability: Clean, well-organized implementation
  • ✅ Test Reliability: Comprehensive test coverage ensures stability

🎉 Conclusion

This is an exemplary implementation that demonstrates strong understanding of the codebase architecture and Go best practices. The dialect system deepening successfully adds valuable functionality while maintaining the high quality standards of the GoSQLX project.

Recommendation: ✅ Approve and merge


@ajitpratap0 ajitpratap0 merged commit a7f35b6 into main Feb 25, 2026
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat: deepen dialect system — dialect-aware parsing beyond keywords

1 participant