Skip to content

fix(workspace): a Go route inside a string literal is not an HTTP provider - #4576

Open
florianaltendorfer wants to merge 1 commit into
repowise-dev:mainfrom
florianaltendorfer:bounty-4563
Open

florianaltendorfer wants to merge 1 commit into
repowise-dev:mainfrom
florianaltendorfer:bounty-4563

Conversation

@florianaltendorfer

Copy link
Copy Markdown
Contributor

Closes #4563.

Summary

  • ScanContext gains in_string(offset), read off a second memoized mask that also blanks string bodies (mask_comments_and_strings(..., strings=True), which already understands Go raw strings). GoDialect.extract drops a route whose match starts in a string, so a test that writes another program's main.go in a backtick literal no longer reports that program's routes as the repo's providers.
  • Only the match start is tested, so a real r.GET("/x", h) still matches even though its path is a string. Other dialects are unchanged, and test files are still scanned for providers.

Related Issues

Closes #4563

Test Plan

  • Tests pass (pytest): new test_go_routes_in_a_raw_string_fixture_are_not_providers in tests/unit/workspace/test_contracts.py (fails on main), plus tests/unit/workspace and tests/unit/ingestion
  • Lint passes (ruff check .)

Checklist

  • My code follows the project's code style
  • I have added tests for new functionality
  • All existing tests still pass
  • I have updated documentation if needed

This branch has not been deployed

No deployments
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.

[Bug] Go routes inside a raw-string test fixture are read as the repo's HTTP providers

1 participant