Order overlapping regex targets by specificity - #852
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Merge Protections🔴 1 of 1 protections blocking · waiting on 👀 reviews
🔴 Require one maintainer reviewWaiting for any of
This rule is failing.All PRs must have at least one approving review from a maintainer before merging.
|
|
The quality checks have failed. Please run |
match_targets claimed most-specific-first ordering, but two re: patterns were sorted lexicographically so a short catch-all could win. Signed-off-by: Gyanu <gyanum.ug20.cse@nitp.ac.in>
b95d5d1 to
4205865
Compare
|
|
|
Quality and DCO are green. The remaining red check is Mergify Merge Protections requiring one maintainer review. Ready whenever someone has a moment to look. |
match_targetsis documented as returning matches from most specific to least specific, and_scheme_from_targetsjust takestargets[0]. For twore:patterns the sort key fell through to lexicographic order of the pattern strings, so a short catch-all likere:.*projcould beatre:.*q_projand the layer got the wrong scheme.Exact names still come first. Regex matches are ordered by pattern length (longer first), then class-name matches as before.
Fixes #847