Unclosed link reference definition title keeps the partial title and the following paragraph's source spans (0.30.0)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 70/100
Hướng nghiên cứu
Bắt đầu từ internal/LinkReferenceDefinitionParser.java tại các phương thức title() và finishReference(). Lỗi là tiêu đề không được đóng sẽ được giữ lại như một phần của định nghĩa và các span nguồn của nó bị tiêu thụ, khiến đoạn văn không còn span nào. Sửa phân tích tiêu đề để dừng ở cuối dòng khi dấu phân cách tiêu đề chưa được đóng, và đảm bảo các span được gán chính xác cho đoạn văn. Chạy các thử nghiệm trình phân tích cú pháp để xác minh.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
When a link reference definition is followed by a line that opens a title delimiter (", ' or () and the title is never closed before the end of the paragraph, commonmark-java 0.30.0 keeps the partial title on the LinkReferenceDefinition and attaches the source spans of the title lines to the definition. The text of those lines is still parsed as a Paragraph (rendered correctly), but that Paragraph has no source spans.
The spec says a title must be enclosed in matching delimiters (0.31.2, §6.3 "link title") and that "No further character may occur" after a definition (§4.7); when the title does not close, the definition has no title and the following lines are a paragraph (this is what cmark and pulldown-cmark do). Issue #315 (fixed by #318 in 0.23.0, "the title was set to the partially-parsed title and the source spans were wrong") covers the sibling case where the title closes and is followed by garbage on the same line; the end-of-paragraph case is not covered by those tests.
Reproduction (0.30.0, Parser.builder().includeSourceSpans(IncludeSourceSpans.BLOCKS_AND_INLINES).build())
Input 1:
[1]: https://example.org/a
(ver tambem https://example.org/b
[1]
Observed:
LinkReferenceDefinition label="1" dest="https://example.org/a" title="ver tambem https://example.org/b\n" spans=[0,26)[27,60)
Paragraph spans=NONE
Text lit="(ver tambem https://example.org/b" spans=[27,60)
Paragraph spans=[62,65)
Link dest="https://example.org/a" title="ver tambem https://example.org/b\n" spans=[62,65)
Expected: definition with title=null and spans [0,26); the paragraph (ver tambem https://example.org/b with spans [27,60). The HTML output already renders the paragraph; only the title and the spans are wrong.
Input 2 (double-quote variant):
[a]: https://example.org/x
"https://example.org/t
mais
[a]
Observed: title="https://example.org/t\nmais\n", definition spans [0,26)[27,49)[50,54), and the Paragraph has no spans.
Input 3 (the #315 case still has a residual span problem): with "t1\nt2" lixo after the definition, the title is correctly discarded, but the span [27,30) of the first title line stays on the definition while the Paragraph only gets [31,39).
Where
internal/LinkReferenceDefinitionParser.java: title() keeps collecting across lines (:251-256) and finishReference() uses the partial title and all collected spans (:275-291); ParagraphParser.java:58-68 then builds the paragraph from the remaining lines after the definition parser already consumed their spans.
Impact
Tools that map nodes back to the source by SourceSpan (we use it to find which parts of a document are covered by definitions) see the paragraph as part of the definition. We work around it on our side by refusing documents where a renderable node has no source position, until a fix is available.
Reproduced with the commonmark-0.30.0.jar from Maven Central on JDK 17 (0.30.0 is the latest release as of 2026-10-06).
Investigated and written with Claude Code while porting a link checker to Android; the reproduction above was run on our side.
- Ngôn ngữ chính
- Java
- Star
- 2.7k
- Fork
- 336
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của commonmark/commonmark-java
-
Second code span not recognised after an unclosed backtick string and another code spanCó thể đã có người làm @TanbirRamim đã nhận 13 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
commonmark/commonmark-java#458 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 74/100
commonmark/commonmark-java#457 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 48/100
commonmark/commonmark-java#443 · 4 bình luận ·
-
Option to define custom flanking/canOpen/canClose rules for delimitersCó thể làm lại được @abhiramaab đã nhận 57 ngày trước và không có pull request nào đang mở. Đang mởenhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
commonmark/commonmark-java#428 · 4 bình luận ·
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
commonmark/commonmark-java#414 · 1 bình luận · 1 reaction ·
Tất cả issue của commonmark/commonmark-java
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
-
team:Lumberjack
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
OpenLiberty/open-liberty#35998 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[BUG] SQS SendMessageBatch accepts more than 10 entries instead of TooManyEntriesInBatchRequestĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
floci-io/floci#5319 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Bug QWP
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100