[arxhr007]

Fixes #294

Summary

Source.get_location() and print_block_string() used str.splitlines(), which recognizes more line boundaries than the GraphQL spec / graphql-js (\r\n, \n, \r only). This produced three issues, all fixed by splitting on \r\n|[\n\r] — the same regex print_source_location() already uses:

1. IndexError crash: an error location computed via get_location() could reference a line that doesn't exist in print_source_location()'s line array (e.g. source containing a vertical tab), making str(GraphQLSyntaxError) itself raise.
2. Wrong line numbers at line starts: splitlines() drops the trailing segment after a final newline, so every character immediately following a line terminator was reported on the previous line (Source("a\nb").get_location(2) → (1,2) instead of (2,1)).
3. Location/serialization drift from graphql-js: \v, \f, \x1c–\x1e, \x85, 
, 
 were counted as line breaks in get_location() (graphql-js counts only \r\n|[\n\r]), and print_block_string() split values on the same too-broad set.

Found by differential-fuzzing parse/print output against graphql-js on mutated documents. After the fix, error locations and printed block strings match graphql-js byte-for-byte on the cases that previously diverged (e.g. "Q\x0b… → both report Unterminated string at 1:30).

Test plan

• pytest tests/ — 3,369 passed, 17 skipped
• New regression tests: line-start + non-GraphQL-terminator locations (test_source.py), get_location-derived location rendering (test_print_location.py), non-GraphQL line breaks in print_block_string (test_block_string.py)
• ruff check + ruff format --check clean on all touched files

[codspeed]

Merging this PR will not alter performance

✅ 20 untouched benchmarks

---

_{Comparing arxhr007:fix/splitlines-location-parity (7524332) with main (f9bdf7c)}

[Cito]

Thanks for reporting and fixing this! It is a clear improvement, so I merge it as it is. I still plan some follow-up changes to bring this code fully in line with GraphQL.js.

Fixed by this PR on main:

• str(error) no longer raises IndexError when the source contains characters like \v, \f, \x85 or \u2028.
• get_location now reports the correct line for positions at the start of a line, and only counts \r\n, \n and \r as line terminators.
• print_block_string now splits lines the same way as GraphQL.js.

Planned as part of the regular porting from GraphQL.js:

• get_location will use the same scanning algorithm as GraphQL.js. The results still differ for positions inside a \r\n (GraphQL.js reports column 0) and positions outside the source body. I did not see these differences in parser errors, only in direct calls.
• The location tests from test: cover source location lookups graphql/graphql-js#4935 will be ported, followed by the upstream changes that share location lookups (perf: share source location lookups graphql/graphql-js#4936 and perf: scan single source locations directly graphql/graphql-js#4958).

Also planned:

• Backporting the fix to the 3.2.x line, because this PR only targets main.
• Removing the leftover or [""] in print_block_string, which can no longer take effect.

I'll take care of that, you don't need to send a separate PR.

[Cito]

The follow-up is done, on main and on js-16.x.x, and will ship in 3.3.2 and 3.2.14:

• get_location now uses the same scanning algorithm as GraphQL.js (60bcd297). Positions inside a \r\n report column 0 and positions outside the source body also match now. I compared it with GraphQL.js v17.1.0 and v16.15.0 on about 100,000 positions and found no differences.
• The location tests from test: cover source location lookups graphql/graphql-js#4935 are ported.
• The leftover or [""] in print_block_string is gone (0aaea717).
• This PR and the changes above are backported to the 3.2.x line (001ca2c2, which keeps your authorship, and 2e681e64).

The upstream performance changes that share location lookups (graphql/graphql-js#4936 and graphql/graphql-js#4958) follow with the regular porting.

Thanks again for reporting and fixing this!

[Cito]

The follow-up is done, on main and on js-16.x.x, and shipped in 3.3.2 and 3.2.14:

• get_location now uses the same scanning algorithm as GraphQL.js (60bcd297). Positions inside a \r\n report column 0 and positions outside the source body also match now. I compared it with GraphQL.js v17.1.0 and v16.15.0 on about 100,000 positions and found no differences.
• The location tests from test: cover source location lookups graphql/graphql-js#4935 are ported.
• The leftover or [""] in print_block_string is gone (0aaea717).
• This PR and the changes above are backported to the 3.2.x line (001ca2c2, which keeps your authorship, and 2e681e64).

The upstream performance changes that share location lookups (graphql/graphql-js#4936 and graphql/graphql-js#4958) are ported as well (0a57746d, 1c7791b8, and on 3.2.x 3489973c, a0e66c11).

Thanks again for reporting and fixing this!