Conversation
## Context Using `include_str!` is a great way to keep docs DRY (single point of truth) and up-to-date. The same contents can be reused in multiple places, and the contents of the file can be used in assertions in unit tests as well. One use case is my crate https://crates.io/crates/path_facts. It is used to display facts about a path on disk. To make a consistent output, in tests, I need to create a temp dir, and manipulate it. But this produces unpredictable output as the tempdir changes every time. In unit tests, I have helpers that normalize these values so the output renders consistently: ``` Path does not exist `/path/to/directory/a.txt/b/c/does_not_exist.txt` ^^^^^ ↳ File, not a dir [✅ read, ✅ write, ❌ execute] ``` I want to show this in my docs as well, but the sanitization infrastructure isn't part of the public interface (and doc tests require you to import only public interfaces). So one solution is to use those contents via an `include_str!` in my unit tests, and then to render the contents in my docs. I can use this approach everywhere EXCEPT for my `lib.rs` module docs, since I'm using `cargo-rdme` to keep my README DRY. ## This PR Adds support for `#![doc = include_str!("<path>")]` (only, no other macros) to cargo-rdme. It does this by parsing the directive and special casing `doc = include_str` and then re-implementing the (relatively simple) macro logic to pull in the contents of that file. Closes orium#178
schneems
force-pushed
the
include-str-doc-support
branch
from
September 23, 2026 21:13
f5a5a4f to
ecf909b
Compare
`include_str!` may be invoked through its fully-qualified `std` path. Match both the bare `include_str` identifier and `std::include_str` so the included content is not silently dropped.
schneems
marked this pull request as ready for review
September 24, 2026 14:35
schneems
marked this pull request as draft
September 24, 2026 14:41
Author
|
Closing in favor of #297 which supports ALL macros and is (therefore) a little less hacky. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Using
include_str!is a great way to keep docs DRY (single point of truth) and up-to-date. The same contents can be reused in multiple places, and the contents of the file can be used in assertions in unit tests as well.One use case is my crate https://crates.io/crates/path_facts. It is used to display facts about a path on disk. To make a consistent output, in tests, I need to create a temp dir, and manipulate it. But this produces unpredictable output as the tempdir changes every time. In unit tests, I have helpers that normalize these values so the output renders consistently:
I want to show this in my docs as well, but the sanitization infrastructure isn't part of the public interface (and doc tests require you to import only public interfaces). So one solution is to use those contents via an
include_str!in my unit tests, and then to render the contents in my docs.I can use this approach everywhere EXCEPT for my
lib.rsmodule docs, since I'm usingcargo-rdmeto keep my README DRY.This PR
Adds support for
# to cargo-rdme. It does this by parsing the directive and special casingdoc = include_strand then re-implementing the (relatively simple) macro logic to pull in the contents of that file.Closes #178