document-features fails when markdown headers (`##`) is used in a TOML string (was "docs.rs builds failing")

[epage]

[INFO] [stderr] warning: target filter specified, but no targets matched; this is a no-op
[INFO] [stderr]  Documenting snapbox v0.6.12 (/opt/rustwide/workdir)
[INFO] [stderr] error: Comment cannot be associated with a feature: "[Unreleased] - ReleaseDate"
[INFO] [stderr]   --> src/lib.rs:44:50
[INFO] [stderr]    |
[INFO] [stderr] 44 | #![cfg_attr(feature = "document-features", doc = document_features::document_features!())]
[INFO] [stderr]    |                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[INFO] [stderr]    |
[INFO] [stderr]    = note: this error originates in the macro `document_features::document_features` (in Nightly builds, run with -Z macro-backtrace for more info)

This happened on snapbox 0.6.12 (https://docs.rs/crate/snapbox/0.6.12/builds/1287788) and 0.6.11 but not before.

If you diff my package between 0.6.10 and 0.6.12, there are no relevant changes, see https://diff.rs/snapbox/0.6.10/0.6.12/Cargo.toml

In fact, [Unreleased] - ReleaseDate does not show up on a dedicated line in my ma manifest but does show up in a nested TOML string (not on its own line)

However, I'm not able to reproduce this locally

$ RUSTFLAGS="--cfg docsrs" cargo +nightly doc --no-deps -F document-features

Anyone else seeing this?

[ogoffart]

I can reproduce the problem locally from your snapbox repository if i first do the cargo package step.

cargo package
cd target/package/snapbox-0.6.12/
cargo  doc --no-deps -F document-features

(doesn't need nightly, this is rust 1.79)

But i can also reproduce with the version 0.6.10 of that crate and with older rust version. So i can understand why this fails, but i cannot understand how it worked before. Anyway, i'll come with a fix

[ogoffart]

I made a "fix" but I realize it's not a fix because it wouldn't have an error anymore, but wouldn't also have any feature.

The strange thing is that there is a difference in the Cargo.toml which is not shown by the diff:

If you look at https://docs.rs/crate/snapbox/0.6.10/source/Cargo.toml , it contains:

[[package.metadata.release.pre-release-replacements]]
exactly = 1
file = "CHANGELOG.md"
replace = "<!-- next-header -->\n## [Unreleased] - ReleaseDate\n"
search = "<!-- next-header -->"

However, from https://docs.rs/crate/snapbox/0.6.11/source/Cargo.toml

[[package.metadata.release.pre-release-replacements]]
exactly = 1
file = "CHANGELOG.md"
replace = """
<!-- next-header -->
## [Unreleased] - ReleaseDate
"""
search = "<!-- next-header -->"

I don't understand why they are different. If I look at the .crate file downloaded by cargo in ~/.cargo/registry/cache/index.crates.io-6f17d22bba15001f/snapbox-0.6.10.crate , it does have the """ version. So why did docs.rs have a different version? Do crates.io change the content of the archive, or did docs.rs somehow re-normalized the Cargo.toml?

(This difference makes the test in this condition being different: https://github.com/slint-ui/document-features/blob/c39c610305de9939ff5b1281cbb4e805fae77068/lib.rs#L257)

[ogoffart]

Fixed in 0.2.9

But the reason why the file Cargo.toml was different for docs.rs than what is in the crate package is still a mystery to me.

[ogoffart]

The new version caused regression so i yanked it for now.

[epage]

Do crates.io change the content of the archive, or did docs.rs somehow re-normalized the Cargo.toml?

Looks like docs.rs is loading and rewriting the Cargo.toml file. Its losing the comment and field ordering. It seems that they were using an old toml version and, on upgrade, it started to match the string generation that cargo package does, making this problem visible.

[epage]

Asking about it at https://rust-lang.zulipchat.com/#narrow/stream/356853-t-docs-rs/topic/Rewriting.20of.20.60Cargo.2Etoml.60

[ogoffart]

should work now in 0.2.10