Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

commonmark reader registers its input twice and stamps nodes with the content-less FileId(0)

已关闭 适合新手
#883 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
78/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
rust
领域
backend

调研方向

阅读crates/pampa/src/readers/commonmark.rs,并将其上下文设置与crates/pampa/src/readers/qmd.rs进行比较。更新crates/pampa/tests/integration/test_diagnostic_path_normalization.rs,尤其是commonmark_reader_source_context_uses_forward_slashes,检查规范化后的路径和输入内容属于FileId(0),且只注册了一个文件。完成标准是 commonmark 节点使用这个包含内容的文件,并且针对性测试通过。

由索引模型根据 Issue 内容生成。

描述

bug

Summary

pampa::readers::commonmark::read registers its input in the SourceContext twice and then points every node's SourceInfo at the wrong entry: the one without content. Line/column mapping for commonmark-read nodes only works today because the sole caller (the pampa CLI's --from commonmark) passes a real path that the first registration reads back from disk. For an in-memory input (anything named like <pandoc.read>), no position in the resulting AST can be turned into a line and column.

Where

crates/pampa/src/readers/commonmark.rs, read:

let mut context = ASTContext::with_filename(filename.to_string());   // (1) add_file(filename, None) -> FileId(0)
let normalized_filename = context.filenames[0].clone();
context
    .source_context
    .add_file(normalized_filename, Some(input.to_string()));          // (2) same path, with content -> FileId(1)
let file_id = FileId(0);                                               // (3) ...but nodes are stamped with FileId(0)

let source_ctx = SourceLocationContext::new(input, file_id);
let pandoc = convert_document_with_source(root, Some(&source_ctx));

SourceContext::add_file (quarto-source-map 0.3.0, context.rs) always pushes a new SourceFile; it does not dedupe by path. So after (2) the context holds two files with the same path: FileId(0) with content: None and a file_info only if std::fs::read_to_string(path) succeeded, and FileId(1) with the actual content. Every SourceInfo::Original the conversion produces names FileId(0).

The qmd reader (readers/qmd.rs, same spot) avoids this by replacing the context before adding the file:

let mut context = ASTContext::with_filename(filename.to_string());
context.source_context = quarto_source_map::SourceContext::new();
context.source_context.add_file(normalized_filename, Some(input_str));

so its FileId(0) is the entry that has the content.

Evidence that it is pinned rather than caught

crates/pampa/tests/integration/test_diagnostic_path_normalization.rs, commonmark_reader_source_context_uses_forward_slashes, asserts on FileId(1) and explains why:

FileId(0) is the entry ASTContext::with_filename creates internally … The fix this test protects is commonmark::read's own second add_file call, which lands at FileId(1)

That test will need to move to FileId(0) with the fix (and could additionally assert the context holds exactly one file).

Consequences

  • With a real on-disk path: works by accident. FileId(0) got a FileInformation from re-reading the file, so map_offset succeeds; FileId(1) is dead weight.
  • With an in-memory input and a synthetic name: FileId(0) has neither content nor file_info. A diagnostic or any map_offset against a commonmark node has an offset into a file the context cannot map. This is the path a Lua pandoc.read(text, "commonmark") would take (separate issue), and the reason to fix this first.
  • Snapshot or provenance tooling that looks at root_file_id() of commonmark nodes gets the content-less entry.

Fix

Mirror the qmd reader: build the context, replace source_context with a fresh one (or skip the with_filename registration), add_file(normalized, Some(input)) once, and use the FileId that call returns instead of a hard-coded FileId(0). Update the test above to assert a single file at FileId(0) with the normalized path and the content.

Environment

Repo at ad283a2cb (2026-10-16); quarto-source-map 0.3.0.

主要语言
Rust
星标
278
派生
19
平均合并
20 小时 23 分钟
30 天内合并 PR
164

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

quarto-dev/q2 的其他 Issue

查看 quarto-dev/q2 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。