path.go (2)

279-283: Fix formatting issue detected by gofumpt.

The linter reports that the file is not properly formatted. The indentation on line 279 appears incorrect.

Apply this diff to fix the formatting:

-	var search = [256]bool{
+	search := [256]bool{
 		wildcardParam:    true,
 		plusParam:        true,
 		paramStarterChar: true,
 	}

---

318-361: Consider extracting constraint parsing logic for better maintainability.

The analyseParameterPart function is complex with deeply nested logic for handling constraints and parameter endings. Consider extracting the constraint boundary detection (lines 339-354) into a separate helper function for improved readability and testability.

Example refactor approach:

func findConstraintBoundaries(search string) (start, end int) {
    start, end = -1, -1
    for i := range search {
        if start == -1 && search[i] == '<' && (i == 0 || search[i-1] != escapeChar) {
            start = i + 1
            continue
        }
        if end == -1 && search[i] == '>' && (i == 0 || search[i-1] != escapeChar) {
            end = i + 1
            break
        }
    }
    return start, end
}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

path.go (2)

284-300: Fix parameter cluster termination logic.

The logic for handling parameter clusters has the same issue identified in the previous reviews. When a cluster of parameter start characters extends to the end of the pattern, the function returns next (the start index) instead of the correct end index.

Apply this fix to handle clusters that extend to the pattern end:

 	if next > 0 && pattern[next] != wildcardParam {
 		// checking the found parameterStartChar is a cluster
 		for i := next + 1; i < len(pattern); i++ {
 			if !search[pattern[i]] {
 				return i - 1
 			}
 		}
-		next = len(pattern) - 1
+		return len(pattern) - 1
 	}
 	return next

---

340-341: Fix incorrect variable reference in constraint detection.

The condition incorrectly references the byte constant paramConstraintStart instead of the local variable parameterConstraintStart for comparison.

Apply this diff to fix the variable reference:

-		if parameterConstraintStart == -1 && search[i] == paramConstraintStart && (i == 0 || search[i-1] != escapeChar) {
+		if parameterConstraintStart == -1 && search[i] == '<' && (i == 0 || search[i-1] != escapeChar) {
 			parameterConstraintStart = i + 1

path.go (1)

351-351: Consider using explicit boolean logic for clarity.

The XOR operation parameterConstraintStart^parameterConstraintEnd >= 0 is mathematically correct but could be more readable.

Consider this more explicit approach for better readability:

-			if parameterConstraintStart^parameterConstraintEnd >= 0 {
+			if (parameterConstraintStart == -1 && parameterConstraintEnd == -1) ||
+			   (parameterConstraintStart != -1 && parameterConstraintEnd != -1) {

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

path.go (8)

279-284: Hoist the lookup table to avoid per-call init cost.

Make the 256-entry search table a package-level var and reuse it. It’s tiny but this function is hot.

Apply:

-	search := [256]bool{
-		wildcardParam:    true,
-		plusParam:        true,
-		paramStarterChar: true,
-	}
+	search := paramStartLookup

Add outside the function:

var paramStartLookup = [256]bool{
	wildcardParam:    true,
	plusParam:        true,
	paramStarterChar: true,
}

---

285-290: Iterate by byte, not rune.

Use a byte-indexed loop to avoid rune decoding overhead in this hot path.

-	for i := range pattern {
+	for i := 0; i < len(pattern); i++ {

---

323-361: End-of-parameter scan: boundary conditions look good; small clarity tweak suggested.

Logic is correct. For readability and to prevent future off-by-one regressions, consider storing base := 1 and commenting that indices in this block are relative to pattern[1:].

---

365-367: Guard against impossible negatives (defensive only).

paramEndPosition can’t be -1 here due to the switch above, but a cheap assert helps future edits.

-	processedPart := pattern[0 : paramEndPosition+1]
+	// paramEndPosition >= 0 guaranteed by switch above
+	processedPart := pattern[0 : paramEndPosition+1]

---

372-373: Constraint slice indexes are correct; add a fast-path when empty.

If < > are adjacent (empty constraints), skip parsing to avoid allocating an empty slice.

-		constraintString := pattern[paramConstraintStartPosition+1 : paramConstraintEndPosition]
+		constraintString := pattern[paramConstraintStartPosition+1 : paramConstraintEndPosition]
+		if len(constraintString) == 0 {
+			// treat as no constraints: <>
+			goto build_segment
+		}

---

417-417: Correct name extraction with constraints; add trim for trailing spaces.

If users accidentally put spaces before <, trimming avoids surprising param names.

-		paramName = RemoveEscapeChar(GetTrimmedParam(pattern[0:paramConstraintStartPosition]))
+		paramName = RemoveEscapeChar(GetTrimmedParam(strings.TrimRight(pattern[0:paramConstraintStartPosition], " ")))

---

432-432: Optional flag detection is right; consider guarding wildcard early.

Minor: short-circuit IsOptional for wildcards to avoid indexing.

-		IsOptional: isWildCard || pattern[paramEndPosition] == optionalParam,
+		IsOptional: isWildCard || (!isWildCard && pattern[paramEndPosition] == optionalParam),

---

279-299: Add focused tests for escapes, clusters, and constraints.

These fast paths are easy to regress. Please add unit tests covering:

• Escaped starters: "\:a", "\\:a" (escaped vs. double-escaped)
• Cluster at EOF: "a::", "a++", "a*:"
• Constraints with/without data: ":id<min(3)>", ":id<>", nested escaped "<regex(\>)>"
• Optional marker inclusion: ":id?" and with trailing delimiter ":id?/"

I can draft them if helpful.

Also applies to: 323-361, 365-367, 372-373, 417-417, 432-432

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

path.go (2)

123-138: Consider moving character maps to package level as suggested.

Per the previous review comment, these boolean maps could be moved outside the functions to the package level for better organization and easier expansion. This change would have minimal performance impact while improving code maintainability.

Consider moving these maps outside the var block to package level:

// Character lookup tables for parameter parsing
var (
	parameterStartChars = [256]bool{
		wildcardParam:    true,
		plusParam:        true,
		paramStarterChar: true,
	}
	parameterEndChars = [256]bool{
		optionalParam:    true,
		paramStarterChar: true,
		escapeChar:       true,
		slashDelimiter:   true,
		'-':              true,
		'.':              true,
	}
)

---

294-311: Fix handling of parameter clusters extending to pattern end.

The current implementation correctly handles parameter clusters that extend to the end of the pattern by returning len(pattern) - 1 on line 308. However, there's a logical issue with the condition on line 301 - it should check next != -1 instead of next > 0 to properly handle clusters starting at position 0.

Apply this diff to fix the cluster detection logic:

-	if next > 0 && pattern[next] != wildcardParam {
+	if next != -1 && pattern[next] != wildcardParam {
		// checking the found parameterStartChar is a cluster
		for i := next + 1; i < len(pattern); i++ {
			if !parameterStartChars[pattern[i]] {
				return i - 1
			}
		}
		return len(pattern) - 1
	}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro