NordSecurity/libtelio

Cargo doc fails with custom `rustdocflags`

Closed this issue · 1 comments

After cloning this repo and running cargo doc (with or without BYPASS_LLT_SECRETS=1):

$ cargo doc
    Updating git repository `https://github.com/NordSecurity/uniffi-rs.git`
 Documenting cfg-if v1.0.0
    Checking quote v1.0.36
 Documenting libc v0.2.155
 Documenting once_cell v1.19.0
    Checking ryu v1.0.18
    Checking getrandom v0.2.15
    Checking lock_api v0.4.12
    Checking parking_lot_core v0.9.10
    Checking socket2 v0.5.7
    Checking signal-hook-registry v1.4.2
    Checking mio v0.8.11
    Checking num_cpus v1.16.0
    Checking slab v0.4.9
    Checking ahash v0.8.11
    Checking pnet_base v0.34.0
    Checking hex v0.4.3
    Checking fnv v1.0.7
 Documenting pin-project-lite v0.2.14
    Checking opaque-debug v0.3.1
error: error reading `./rustdoc/header.html`: No such file or directory (os error 2)

error: could not document `cfg-if`

But obviously that file exists. This might to be related to this bug in cargo doc, maybe? rust-lang/rust#126638

The fix is simple:

$ git diff
diff --git a/.cargo/config b/.cargo/config
index 79eafab2..22f6b399 100644
--- a/.cargo/config
+++ b/.cargo/config
@@ -1,10 +1,5 @@
 [build]
 rustflags = [ "-Aunknown_lints" ]
-rustdocflags = [
-  "--html-in-header", "./rustdoc/header.html",
-  "--html-after-content", "./rustdoc/multi-code.html",
-  "--html-after-content", "./rustdoc/footer.html",
-]
 
 [target.'cfg(unix)']
 runner = './test_runner.sh'

I'm opening this issue because I do wonder whether anyone else can reproduce this?

Hi,

Thanks for reporting the issue. I can confirm, that it is reproducible.

Unfortunately, the fix is not that easy :/, because we have this integration documentation being used publicly, as well as internally at NordSecurity. One thing it provides is examples for integration with non-rust languages. Which is implemented using that ./rustdoc-multicode.html. Therefore removing it would break this integration documentation.

It seems like the issue is related to cargo doc using different working directories for dependencies (although this is more of a guess then fact). Currently we are using cargo doc --no-deps in CI to generate docs, which is probably good enough compromise until cargo fixes working directory issues.

Thanks for bringing my attention to the rust issue, I will mention, this --no-deps caveat in the rust issue, in the hopes, that it will help track down the issue for rust docs.