SONARPY-2729 Fix crash when Jupyter notebook source arrays contain multiline strings

[mallory-scotton]

SONARPY-2729

Analysis crashed with IllegalStateException: No IPythonLocation found for line N on notebooks where "source" was an array and one of its entries
contained embedded newlines. That's valid per the ipynb schema, but
IpynbNotebookParser.parseSourceArray counted every array entry as exactly
one line. An entry spanning several lines only added a single entry to the
line-location map, so the map and the generated source drifted apart -
and once the parser reached a line number the map didn't have, it threw.

Fixed by pulling the per-line splitting logic already used for plain-string
"source" values out into a shared helper, then reusing it for array entries
that contain embedded newlines. Single-line entries take the exact same
path as before.

I added notebook_multiline_string_in_array.ipynb to reproduce the reported
payload, a unit test in IpynbNotebookParserTest checking the location map
gets one entry per line, and an end-to-end test in
IpynbNotebookParserScannerTest that runs the real IPythonTreeMaker/
TokenEnricher path that used to throw. Full python-frontend suite and
the notebook tests in python-commons both pass.

Green build: https://github.com/SonarSource/sonar-python/actions/runs/29499453281/job/87624388023

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Refactors the source array parser to correctly map multiline strings by sharing existing splitting logic, resolving the location drift and crash issues. Comprehensive unit and end-to-end tests verify the fix.

✅ 1 resolved

✅ Edge Case: Multiline non-last array element without trailing newline misaligns location map

📄 python-frontend/src/main/java/org/sonar/plugins/python/IpynbNotebookParser.java:277-291 📄 python-frontend/src/main/java/org/sonar/plugins/python/IpynbNotebookParser.java:320-334
In addSourceArrayElement, a source-array element that contains embedded newlines but does NOT end with "
" (e.g. ["a
b", "c"]) is concatenated to the next element as "a
bc" (2 physical lines), yet each split line calls addLineToSource, which increments the aggregated line counter and adds a locationMap entry. This produces one more location entry than there are physical lines, so subsequent tokens on the joined line (and the cell delimiter) resolve to the wrong IPythonLocation (wrong column), producing off positions rather than a crash. The common case (elements ending in "
", or a single multiline element as in the added test) is handled correctly; only mid-array multiline elements lacking a trailing newline drift. Consider not incrementing the line counter for the final split line when the element has no trailing newline (i.e. let the next element continue the same physical line), or add a regression test for the ["a
b","c"] shape.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Refactors the source array parser to correctly map multiline strings by sharing existing splitting logic, resolving the location drift and crash issues. Comprehensive unit and end-to-end tests verify the fix.

✅ 1 resolved

✅ Edge Case: Multiline non-last array element without trailing newline misaligns location map

📄 python-frontend/src/main/java/org/sonar/plugins/python/IpynbNotebookParser.java:277-291 📄 python-frontend/src/main/java/org/sonar/plugins/python/IpynbNotebookParser.java:320-334
In addSourceArrayElement, a source-array element that contains embedded newlines but does NOT end with "
" (e.g. ["a
b", "c"]) is concatenated to the next element as "a
bc" (2 physical lines), yet each split line calls addLineToSource, which increments the aggregated line counter and adds a locationMap entry. This produces one more location entry than there are physical lines, so subsequent tokens on the joined line (and the cell delimiter) resolve to the wrong IPythonLocation (wrong column), producing off positions rather than a crash. The common case (elements ending in "
", or a single multiline element as in the added test) is handled correctly; only mid-array multiline elements lacking a trailing newline drift. Consider not incrementing the line counter for the final split line when the element has no trailing newline (i.e. let the next element continue the same physical line), or add a regression test for the ["a
b","c"] shape.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}