Conversation
override_stars and override_rust_percentage are documented as per-section overrides keyed on the markdown header level, but they were called for every Event::Text, not just heading text. last_level is only updated on Tag::Heading, so any body text under a level-2 header that contains "Resources" matched too. A single list item under "## Applications" whose description contains the word "Resources" therefore sets required_stars to 0 and required_rust_percentage to 0.0 for the rest of that section, including all of its ### subsections, until the next level-2 header. The popularity gate silently stops rejecting anything. Track whether we are inside a heading and only consider the overrides there. The current README is unaffected: its only non-heading "Resources" text sits inside the Resources section itself, where the override is already active.
|
The red The same job fails the same way on #2805, which changes README.md only and no Rust code at all: https://github.com/rust-unofficial/awesome-rust/actions/runs/34991379111/job/104456663710, same single URL, same error line. I also checked the URL from here just now — I've left that line alone rather than fold an unrelated README edit into this PR, so the fix is yours to place wherever it fits best. Found by a defect-hunting pipeline I build and run (Dev-next-gen), using Claude Code with Anthropic's Claude Opus 5. |
|
Merged main in e0093e4, which picks up the arewelearningyet.com link fix; |
2 participants
I was reading the checker and noticed that
override_starsandoverride_rust_percentageare documented as per-section overrides keyed on the markdown header level, but they are called from theEvent::Textarm for every text event, not only for heading text.last_levelis only updated onTag::Heading, so it keeps the level of the last header seen while we walk through the body of that section. The result is that any body text under a level-2 header that contains the word "Resources" matchesoverride_stars(2, text)just as the## Resourcesheader does.Concretely: a single list item under
## Applicationswhose description happens to contain the word "Resources" setsrequired_starsto 0 andrequired_rust_percentageto 0.0. The reset only fires on the next header of the same level, so the relaxed thresholds stay in force for the rest of## Applications, including every###subsection under it, until## Development tools. The popularity gate quietly stops rejecting anything in between.I reproduced it with a pre-seeded
results/popularity.yamlso the run needs no network. A repo cached at 1 star, alone under## Applications:Adding one item above it whose description reads
- Resources for dealing with things.:and the same holds when the low-star item sits under a
###subheading further down. With this change both cases are rejected again, while## Resourcesitself still relaxes the thresholds exactly as before.The fix is to track whether we are inside a heading and only look at the overrides there. The current README is unaffected: I dumped every
Resourcestext event through the same parser, and the only non-heading one is "Programming Community Curated Resources for Learning Rust", which sits inside the Resources section where the override is already active, so re-applying it was a no-op. The other occurrence is the table of contents entry at level 1, which never matched.cargo fmt -- --checkandcargo buildare clean.Found by a defect-hunting pipeline I build and run (Dev-next-gen), using Claude Code with Anthropic's Claude Opus 5.