Docs.rs: Crate failed to build

Created on 26 Aug 2016  ·  432Comments  ·  Source: rust-lang/docs.rs

Docs.rs may have failed to build some crates for various reasons (missing dependency on build machine or bad configuration etc).

You can report them into this issue.

C-bug

Most helpful comment

Latest version of rustc (1.26.0-dev (5c1d29af0 2018-03-03)) is finally up and running on docs.rs. Some missing docs fixes reported in this thread:

And now docs.rs is building every crate that have failed to build since last rustc update.

All 432 comments

There is a problem on crates that have url-0.5.9 dependency. If you check the build log cargo is returning error with: url-0.5.9/Cargo.toml:14:3 expected a newline after table definition. This is a warning when we use standalone cargo, but it is returning an Err as a library. I wasn't able to figure out how to bypass this.

Indeed, I have seen this warning in my own crates too before. I am not sure there is a way around it, except maybe using a fork of url-0.5.9 with the fix and using Cargo replace. I wouldn't consider that a solution though :wink:

I have also seen crates depending on compiler internals that did not compile with the particular nightly version used. diesel_codegen for example. But I guess making this work is a non-goal.

https://docs.rs/crate/c-ares-sys/ (and as a result, https://docs.rs/crate/c-ares/ too).

Need to install libtool to compile the C library being wrapped.

Or, install c-ares directly so that we find the package and don't need to compile our own version - either is supposed to work.

https://docs.rs/crate/probe/ appears to have only attempted a few older versions, which don't work with current nightly, but the current 0.1.6 should be fine.

@cuviper thanks for reporting. Looks like docs.rs returned IoError when trying to build probe 0.1.4+. I'll fix it tomorrow morning.

First - cool stuff! :-)

Second, about https://docs.rs/crate/dbus/0.3.4

Package dbus-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing 'dbus-1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'dbus-1' found

https://docs.rs/crate/alsa/0.1.2 fails with the same error, but missing alsa.pc instead of dbus-1.pc.

Is there some way for me as crate author to indicate that docs.rs needs to install these before compiling my crates? Because this seems like it's not going to scale very well as the number of crates grow with the fast-growing Rust ecosystem...

Thanks for running this service!

I noticed that systemd crates fails to build because of missing C development files: https://docs.rs/crate/systemd/0.0.10

This requires libsystemd-dev (or equivalent) on the building machine.

By the way, what is the OS of the building environment here? Does it have any package manager that could be re-used to install system dependencies on demand? I'm thinking about using the metadata table to encode this information to drive an external package manager.

@cuviper for some reason cargo is not generating any documentation when we use target option with your crate. I fixed the IoError in docs.rs, probe is available now, but only default platform worked.

@diwic dbus and alsa building fine now.

@lucab docs.rs is using Debian. I am planning to add docs.rs metadata table to Cargo.toml, so people can define extra features and system dependencies.

BTW I installed systemd development files but looks like systemd crate (or one of its dependency) doesn't work with recent nightly.

@onur I see you’ve somehow ended up running build.rs stuff when generating documentation. That’s generally unnecessary for majority of crates (notable exceptions are the stuff which use syntex/lalrpop-like scheme to generate code) and plain rustdoc should generate documentation for these crates just fine without any of the dependency libraries existing.

@nagisa I am not sure how to achieve that but I am using Cargo::ops::compile_pkg to generate documentation. This function is building docs.

https://docs.rs/crate/notify-rust/3.1.1 failed to build, due to the same problems as dbus is there a way to manually trigger rebuilding?

@hoodie docs.rs has rebuilt every version of notify-rust.

I was planning to add a button to automate rebuild requests but I changed my mind. People can abuse this kind of feature.

Perhaps there is a way to authenticate as the crate owner via github?

@msierks lua crate is looking for lua 5.3.3, and Debian only have lua 5.3.1. There is not much I can do in this case.

this raises the question, do you build each crate completely or just run cargo doc? And if the latter, does cargo doc really need to have all build dependencies? This looks like a potential upstream improvement. Does it @steveklabnik?

@hoodie cargo doc is building crate first.

@onur hmm, well it appears the next release rust-lua will have lua 5.3.3 bundled with it. Someone correct me if I'm wrong.

And if the latter, does cargo doc really need to have all build dependencies?

Yes, because in order to generate docs, it has to build the library, thanks to things like cfg.

Thanks for making a great service. https://docs.rs/crate/nodrop-union/0.1.8 simply needs a newer nightly to build. Will it be retried automatically?

@bluss currently there is no way to trigger rebuilds automatically. I'll upgrade rustc to latest nightly tomorrow.

Any update on this?

@bluss nodrop-union have docs now.

@dimbleby sorry I didn't see your first message, c-ares-sys and c-ares should work fine now.

Great, many thanks!

docs.rs didn't recognize that I updated my crate Prophet from 0.0.1 to 0.0.2. It is an important update since many things (also documentation) have changed and because I yanked the old version.
docs.rs didn't list my crate in its recent released list, so I guess it was dropped or simply missed.
Is there anything I can do? At the moment I heavily depend on the great documentation generation of docs.rs. :)

sorry @Robbepop, I think I accidentally removed prophet from build queue while I was trying to remove google-* crates because of #46 yesterday. It is fixed now.

okay thank you very much! I too was confused about the huge number of google API bindings. :D

could you install libudev-dev? :) My crate fails to build without it. My crate is called block-utils

@cholcombe973 done

@onur awesome!!

My crate needs llvm-3.8 clang-3.8 libclang-3.8-dev and I guess a lot of other crates do too that use bindgen.

My crate also needs libv8-5.4-dev or later and libicu-dev for the actual functionality.

Maybe at this point #50 should be considered?

https://docs.rs/crate/v8

@dflemstr when I moved docs.rs to its new host I forgot to link libclang.so to libclang.so.1. For some reason clang-sys doesn't accept libclang.so.1. That is why all crates that depends on clang-sys failed to build. This issue is fixed now, too bad I can't reverse query and find out which crates requires a rebuild. bindgen is fixed since you mentioned.

And unfortunately libv8-5.4-dev is not available for Debian jessie. Hopefully, #29 and #50 will fix this issues.

Hey @onur, I am building a crate that depends on the arm-none-eabi-gcc binary to set up cross compilation for a microcontroller target. The library affected is here: https://docs.rs/crate/teensy3/0.1.2

Would it be possible to install the gcc-arm-none-eabi package for Debian and add arm-none-eabi-gcc to the $PATH?

Done @jamesmunns

@onur Thanks so much! Is it possible to retrigger the build? Or will it happen automatically?

Oops, just saw its already done. Thanks again!

https://docs.rs/crate/directwrite/0.0.5 (builds only on Windows I guess, I tested it using the MSVC toolchain)

My crates https://docs.rs/crate/midir and https://docs.rs/crate/winrt/ didn't compile. The former relies on alsa, which should be fixed now according to https://github.com/onur/docs.rs/issues/23#issuecomment-242946162 so it needs a rebuild, the latter seems to have missed that there is now a version 0.1.0 on crates.io ...

@Boddlnagg both of them fixed. I am not sure why docs.rs skipped winrt-0.1.0. Build queue is not working as expected I guess.

@onur the Gfapi-sys crate docs can be fixed if glusterfs-common is installed. That should give it the build files it's looking for

Is there anything I have to do to get docs.rs to start looking for my crate or does it automatically pick up all new crates on crates.io? Documentation for my crate is missing: https://crates.io/crates/ttl_cache

@stusmall looks like build thread panicked yesterday for some reason, its fixed and docs.rs should build all crates now.

@onur Thanks for the quick reply! Will I need to take any action on my part?

rusty_alfred compiles on rustc 1.14.0-nightly (5665bdf3e 2016-11-02), but rustc 1.14.0-nightly (6dc035ed9 2016-10-15) is being used on docs.rs, and serde_codegen fails to build.

@jkcclemens rusty_alfred is building fine with latest nightly now.

Scaproust v0.2.0 failed to build, because the version of rust used is too old to build clippy. The build used rustc 1.14.0-nightly (cae6ab1c4 2016-11-05), to work it should be using rustc 1.15.0-nightly (0bd2ce62b 2016-11-19).

coreaudio-rs fails, I'm guessing as it requires OS X.

https://docs.rs/crate/ruma-events/0.1.0 failed cause it's using a version of nightly Rust that is too old. ruma-events uses the macros 1.1 version of Serde, which needs a more recent nightly.

@jimmycuadra fixed!

That was fast! Thank you! ❤️ ❤️ ❤️

https://docs.rs/crate/smbc/0.1.0 needs libsmbclient-dev to build successfully.

@grossws libsmbclient-dev is installed and smbc is building fine now.

@onur, thanks

The various Allegro crates (e.g. https://docs.rs/crate/allegro/0.0.29) need Allegro installed.

liballegro5-dev
liballegro-acodec5-dev
liballegro-audio5-dev
liballegro-dialog5-dev
liballegro-image5-dev
liballegro-physfs5-dev
liballegro-ttf5-dev 

@SiegeLord done
edit: let me build all allegro crates

@SiegeLord all allegro crates successfully built

I have a crate which provides bindings for a C++ library, and compiles that library in build.rs using CMake. For whatever reason, the C++ library failed to build, but it seems like it should still be possible to at least compile the documentation, since that's pure Rust.

https://docs.rs/crate/cryptominisat/5.0.1

coremidi fails because it depends on OSX libraries that fail to build. Is there any solution for those cases ? is the build (specifically the linking) really required to generate the docs ?

@Storyyeller fixed cryptominisat.

@chris-zen unfortunately it is not possible to build crates that works only on non-linux systems. And yes we need to build a crate to generated documentation.

@onur sad to hear that. I created an issue with an idea to overcome this limitation #93 . Let me know what do you think about that.

The gio docs failed to generate, seemingly because the glib (headers) package wasn't installed on the build machine.

The erlang_nif_sys crate requires an installation of erlang to build.

It would be nice to get this fixed since the Rustler crate depends on it.

https://docs.rs/crate/bart_derive/0.0.1/builds/38291 failed because the compiler in use is a too old nightly build.

I see the problem of "wrong nightly" has been repeating. Perhaps it could be an idea to allow packages to declare which version they need, and use this automatically with rustup? The declaration could for example be in [package.metadata] in Cargo.toml.

Now, I am using a feature that's only available on nightly (proc_macro). As long as the documentation building works when that feature hits rustc stable, I'm happy :)

@maghoff that is a great idea, maybe I can expand #73 and add a field for required minimum rustc version.

BTW I usually update rustc more often but there is a openssl 0.9 transition going on, and because of this docs.rs is stuck with an old version of cargo. rustc is usually working fine with this but there is always a risk to break.

@hansihe sorry I just saw your message :/ erlang_nif-sys is fixed now.

liblzma is missing for this crate.

@mathstuf fixed along with rust-lzma.

serde_json 0.9.2 fails

@onur libevent dev headers are missing for this crate https://docs.rs/crate/couchbase-sys/0.1.1/builds/40187 (it depends on libevent, openssl and cmake)

@daschl I believe it's not enough: https://docs.rs/crate/couchbase-sys/0.1.1/builds/40192

@onur darn, the bindgen build.rs execution needs clang (it recommends 3.9) - is that one on the machine by chance? (https://docs.rs/crate/bindgen mentions it too)

@dashi installed clang-3.8 (that is latest version Debian stable has) clang_Cursor_isAnonymous is available on clang-3.7+. But now it is complaining about stddef.h.

@onur sorry that this is a PITA :/ , but if we work through this other crates using bindgen might also benefit. According to this page http://stackoverflow.com/questions/20587228/clang-error-stddef-file-not-found it could be a bug in ubuntu/debian and manually symlinking might help.

Happy to take the discussion elsewhere if you prefer to (gitter, irc,...). Maybe it is in libclang-common-3.8-dev ?

@onur looks like its working, thanks! 👍 can you also rerun the job for couchbase which depends on the sys one and should now also work? Thanks much :)

@daschl looks like I installed every libclang-dev (3.8) package but forgot to install actual clang-3.8 :)

It is building couchbase now.

@onur perfect, thanks! I wonder if other bindgen dependent libs like https://docs.rs/crate/libtensorflow-sys/0.0.2/builds/12475 now also work..

@onur for blkid-sys i need libblkid-dev installed :)

Hi,

pcsc crate failed to build due to missing libpcsclite-dev package in your vagrant image.
Could you please add it ?

Thank you

@cholcombe973 @lexxvir blkid and pcsc crates building fine now.

@onur thanks!

On Feb 6, 2017 12:32 AM, "Onur Aslan" notifications@github.com wrote:

@cholcombe973 https://github.com/cholcombe973 @lexxvir
https://github.com/lexxvir blkid and pcsc is building fine now.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/onur/docs.rs/issues/23#issuecomment-277614298, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC6qE5HrNA-5y7TpsaQYNuR0TmxkGAnnks5rZtqRgaJpZM4Jt4a6
.

libudev-rs and libudev-sys need the libudev-dev package.

upgrade openssl to at least 1.0.2?

@bluejekyll done and fixed trust-dns and trust-dns-server.

The x86_64 crate failed to build because it uses the new x86-interrupt ABI, which is only available on newer nightlies.

@phil-opp I was planning to update rustc with recent css changes but it can wait and I think it is looking fine.

@onur Thanks a lot!

https://docs.rs/crate/sfml-modstream/0.1.1/builds/45125

Weird that https://docs.rs/sfml/0.12.0/sfml/ builds fine, but this fails with not being able to find the SFML system libraries.

@crumblingstatue sfml-modstream is building fine now.

@onur Thank you!

multistr is missing too

@clarcharr multistr doesn't work on rustc 1.17.0-nightly (134c4a0f0 2017-03-20). IDK if it is working on latest nightly but I can't update nightly right now because of rust-lang/rust#40912.

@onur I have problems compiling this crate. The required libraries from ffmpeg 2.8 are libavcodec-dev, libavformat-dev and libavdevice-dev. Thanks in advance!

@danielrs I installed required packages but looks like it's failing to build src/libearwax.c.

@onur Just fixed it with a new release. Thank you!

My crate failed to build because it depends on a feature that was added recently but the build environment is using a nightly from last month. Any chance the nightly version can be updated? rust-lang/rust#40912 has been marked as fixed.

@japaric done!

Awesome! Thanks, @onur.

My crate https://docs.rs/crate/clingo-sys/0.1.2 failed to build.
cargo doc worked fine on my machine with rustc 1.16.0.

@sthiele thanks for reporting. Docs.rs is using Debian stable and g++-4.9. You need to pass -std=c++11 to g++ when building libgringo to make it work.

@onur Thanks, that worked!

Hi @onur! I've published crates.io's code (crate name: cargo-registry) on crates.io to get docs.rs docs to help contributors, but building the crate needs postgres:

/usr/bin/ld: cannot find -lpq

I'm not sure what the packages are called on debian exactly, on ubuntu the packages we need are:

postgresql
postgresql-contrib
libpq-dev

on fedora:

postgresql-server
postgresql-contrib

Thanks! ❤️

Hi @carols10cents, it's fixed and cargo-registry is building fine now.

@onur wow, that was fast!!! thank you!!! ❤️

Installing

- libnl-3-dev
- libnl-genl-3-dev
- libnl-route-3-dev

would be great too for networking libraries. ibverbs doesn't currently build because of this.

@jonhoo done!

https://docs.rs/crate/bio/ did not build in the last update due to a temporal bug in nightly. Could you rebuild it? Btw. wouldn't it be better to try building on stable as well, at least as a fallback?

@johanneskoester done!

https://docs.rs/crate/rust-htslib did not build in the last update, due to a nightly issue. Can you please rebuild?

https://docs.rs/crate/openexr/ isn't building docs because of the missing OpenEXR 2.2 dependency on the build system.

@cessen sorry but Debian jessie have only openexr 1.6.1 and openexr crate is looking for > 2.0. There is not much I can do in this case but I am planning to upgrade distribution soon.

@onur
Ah, no worries. Looking forward to the dist upgrade, then! :-)

https://docs.rs/crate/amiwo/0.2.3 isn't building because it fails to compile rocket_codegen v0.2.7 which requires the latest nightly build (1.19.0-nightly (2017-05-26))

@bgbahoue rustc is updated now and amiwo should build fine.

https://docs.rs/crate/ovr-sys/0.1.0/builds/61443 I've added the docs.rs metadata to Cargo.toml, but it looks like crates.io stripped it out again when "normalising" the file, so docs.rs isn't seeing the metadata.

@dylanede thanks for reporting. Looks like I have to read metadata from Cargo.toml.orig or maybe cargo can keep package.metadata section.

And default-target is intended to redirect documentation links to a specific target (it doesn't work yet). It is not changing host by any means. Docs.rs will always use x86_64-unknown-linux-gnu host machine and if your crate doesn't work on Linux, it may never appear on docs.rs.

https://docs.rs/crate/rsvg/0.1.3

Needs librsvg as a dependency, which is not found.

@selaux fixed!

Thx

libavahi-compat-libdnssd-dev would be nice to have (https://docs.rs/crate/async-dnssd/0.2.0)

https://docs.rs/crate/he_di/0.2.0
A dependency was missing but it is now available on crates.io

BTW is there a way to rerun whichever script you are using to generate docs to prevent reporting a bug in such cases?

Thanks

@bgbahoue fixed. Currently only I can rebuild crates. I was planning to give users ability to rebuild crates but I am afraid someone may abuse this kind of feature and cause DOS issues.

Unfortunately you might be right :( Thanks for rebuilding the crate!

https://docs.rs/crate/scroll/0.6.0/builds/61139

$ cratesfyi ...
    Updating registry `https://github.com/rust-lang/crates.io-index`
thread 'main' panicked at 'ChainedError {
    error: failed to fetch `https://github.com/rust-lang/crates.io-index`,
    cause: ChainedError {
        error: failed to authenticate when downloading repository
        attempted to find username/password via git's `credential.helper` support, but failed,
        cause: Error {
            code: -1,
            klass: 7,
            message: "Config value \'credential.helper\' was not found"
        }
    }
}', src/bin/cratesfyi.rs:136

Hi, would it be possible to get LLVM installed? Preferably multiple versions since my library will need to work with more than one, though I suppose I could set a default. https://docs.rs/crate/inkwell/0.0.0/builds/63589

rexiv2 and gexiv2-sys need libgexiv2-dev to build.

len-trait is missing docs because of OsString::shrink_to_fit, which was recently stabilised for 1.19. Mind bumping the nightly?

@felixc fixed rexiv2.

@clarcharr sure I'll update nightly this evening.

@TheDan64 llvm-3.8 and llvm-3.9 already installed in build machine, but looks like inkwell is looking for llvm-3.7 and it's removed from Debian :(

@onur okay, thanks anyway. I can probably have it default to latest eventually. Are you be able to add 4.0?

I am sorry @TheDan64 but Debian 9 only shipped with llvm 3.8 and 3.9. llvm is usually getting backported to Debian stable but it may take some time.

linked_list_allocator failed because it uses the relatively new alloc::allocator::Alloc trait, which was added in https://github.com/rust-lang/rust/pull/42313.

I finally managed to update rustc, took a while because of #135. @clarcharr and @phil-opp both crates are fixed now.

Thanks!

tokio-file failed fails because it uses FreeBSD-specific features, and so can't compile on Linux.

https://docs.rs/crate/grpcio/0.1.0 fail due to missing go. Go is required to build boringssl, which is one of the dependencies of this crate.

https://docs.rs/speck-cbc/0.1.1 failed to build due to use of the unstable feature const_fn.

It seems to me like https://docs.rs/crate/prettytable-rs/ doesn't build because of a failure in docs.rs

https://docs.rs/crate/ramp/0.3.7 failed to build because of a recent unstable API change. Presumably, the compiler wasn't updated before the build

Hi guys. I'll update rust compiler today.

I came here to complain about my crate (x264-framing) not showing but damn @onur how do you find the time to respond to all these requests?

@quadrupleslap fixed x264-framing and usually installing one or more dependency is fixing problems so it's not a big deal :-)

BTW guys I am aware that it's been a while since last time I updated rustc but unfortunately I can't find my OSX flash drive, I will keep looking or create another one this week.

@onur Ping on rustc update

I finally updated rustc and secured OSX flash drive. It took a while, and hopefully this won't happen again in future.

@cedenday fixed spec-cbc.
@doomrobo fixed ramp.
@BusyJay fixed grpcio.
@abonander do you have any specific crates affected by old rustc?

I think, it will be better if I rebuild every crate released since last rustc update.

@onur multipart-async but I fixed it so that it didn't need any recently stabilized APIs.

Some crates can't compile for an x86_64-unknown-linux-gnu target, but cross-compiling Rust is easy. Would it be possible to allow crates to specify the target architecture used for generating docs?

@asomers that's what I was thinking with default-target in package.metadata.docs.rs. Then we got another idea in #141 but this may require some work.

I am having a problem building rapt crate: https://docs.rs/crate/rapt/0.1.4/builds/69948

docs.rs' portion of Cargo manifest (https://github.com/ropes-rs/rapt/blob/master/Cargo.toml#L28-L30):

[package.metadata.docs.rs]
all-features = true
dependencies = ["libssl-dev"]

I just spun up a fresh Jessie instance, installed libssl-dev, and cargo doc --all-features worked just fine.

What am I missing?

@yrashk thanks for reporting.

Issue is openssl-sys-extras crate, it is already removed from openssl crate and no longer supported. Since docs.rs build system upgraded to Debian stretch, libssl-dev is also upgraded to openssl 1.1. This crate only works with openssl 1.0. Installing libssl1.0-dev package should be enough to fix this issue but installing this package is breaking so many other system packages. So docs.rs build machine only have openssl 1.1 library, I still couldn't find a solution for this and only few packages affected from this issue and netopt (dependency of your crate) is also one of them.

I don't have a solution for this right now and unfortunately docs.rs doesn't support crates that requires openssl 1.0.

Hi @onur, prost-build 0.2.0 failed to generate. The crate relies on environment variables which are set in the build.rs. Does docs.rs support the build.rs cargo:rustc-env directive? Is there a known workaround for this?

CC danburkert/prost#28

Hey @onur, I have a failed build here: https://docs.rs/crate/hub-sdk/0.3.4/builds/70371 - The cargo doc runs fine for me, and I am not sure how to correct this.

@jamesmunns clearing cache fixed hub-sdk. IDK why rustc tried to use old version instead of compiling new one if a newest version of cookie is available. This might be a bug in rustc or cargo.

Thank you @onur!

Hi @onur, https://docs.rs/crate/plist-sys needs libplist as a dependency, could you install it?

@moriturus done

@onur Thank you!

Hi @onur -- https://docs.rs/crate/maud/0.17.1/builds/67352 failed because the nightly version was too old at the time. Can you please trigger a rebuild?

Sure @lfairy, I can update rustc this evening, ohh nvm rebuild is enough for maud, too bad nobody realized until now and it's fixed now.

I can confirm that that the docs have been rebuilt. Thanks for the quick turnaround @onur!

Hi. pocketsphinx 0.6.0 (and pocketsphinx-sys 0.5.0) requires libpocketsphinx1 on Debian to build. Thanks.

@kennytm done!

stream-vbyte 0.3.0 failed because a dependency (x86intrin) was built without target-feature, even though this was in Cargo.toml:

[package.metadata.docs.rs]
all-features = true
rustc-args = ["-C", "target-feature=+ssse3,+sse4.1"]

For local dev I use RUSTFLAGS='-C target-feature=+ssse3,+sse4.1'. Is there a better way to translate that to docs.rs config?

@marshallpierce you need to use rustdoc-args instead of rustc-args. I really need to add some documentation about docs.rs metadata.

@onur I tried that in 0.3.1 and that didn't work either: https://docs.rs/crate/stream-vbyte/0.3.1/builds/73198. rustdoc doesn't have -C, nor does it have --target-feature.

If you look at the build output of the 0.3.0 build, it doesn't look like the requested target-feature flag was being applied (the string sse4.1 doesn't appear in the log, for instance). Compare that with the output from locally running RUSTFLAGS='-C target-feature=+ssse3,+sse4.1' cg +nightly doc -v --all-features, which shows that the rustc (but not rustdoc) invocations are getting the target-feature:

     Running `rustdoc --crate-name x86intrin /home/mbp/.cargo/registry/src/github.com-1ecc6299db9ec823/x86intrin-0.4.3/src/lib.rs -o /home/mbp/dev/opensource/stream-vbyte-rust/target/doc -L dependency=/home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps`
     Running `rustdoc --crate-name byteorder /home/mbp/.cargo/registry/src/github.com-1ecc6299db9ec823/byteorder-1.1.0/src/lib.rs -o /home/mbp/dev/opensource/stream-vbyte-rust/target/doc --cfg 'feature="default"' --cfg 'feature="std"' -L dependency=/home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps`
     Running `rustc --crate-name x86intrin /home/mbp/.cargo/registry/src/github.com-1ecc6299db9ec823/x86intrin-0.4.3/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=bb7bf908948ddc5c -C extra-filename=-bb7bf908948ddc5c --out-dir /home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps -L dependency=/home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps --cap-lints allow -C 'target-feature=+ssse3,+sse4.1'`
     Running `rustc --crate-name byteorder /home/mbp/.cargo/registry/src/github.com-1ecc6299db9ec823/byteorder-1.1.0/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=ebccca36a5b1fdfa -C extra-filename=-ebccca36a5b1fdfa --out-dir /home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps -L dependency=/home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps --cap-lints allow -C 'target-feature=+ssse3,+sse4.1'`
 Documenting stream-vbyte v0.3.1 (file:///home/mbp/dev/opensource/stream-vbyte-rust)
     Running `rustdoc --crate-name stream_vbyte src/lib.rs -o /home/mbp/dev/opensource/stream-vbyte-rust/target/doc --cfg 'feature="default"' --cfg 'feature="x86_sse41"' --cfg 'feature="x86_ssse3"' --cfg 'feature="x86intrin"' -L dependency=/home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps --extern x86intrin=/home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps/libx86intrin-bb7bf908948ddc5c.rlib --extern byteorder=/home/mbp/dev/opensource/stream-vbyte-rust/target/debug/deps/libbyteorder-ebccca36a5b1fdfa.rlib`
    Finished dev [unoptimized + debuginfo] target(s) in 2.4 secs

@marshallpierce I see the issue now and passing some rustc args to cargo with cargo's CompileOptions caused some other issues in docs.rs when I first introduced docs.rs metadata. Docs.rs never runs rustc on main crate and target_rustc_args meant to run rustc args on main crate. And for this reason I removed rustc_args from docs.rs metadata.

But now instead of setting target_rustc_args in CompileOptions, docs.rs is setting RUSTFLAGS environment variable based on package.metadata.docs.rs.rustc_args.

I am sorry I caused you to upload another version of stream-vbyte, fd4d7a0 should fix this issue and I already tested with stream-vbyte 0.3.0. I believe it is working fine but you need to remove rustdoc_args from docs.rs metadata and upload a new version to make it work with latest version of stream-vbyte :(

@onur no worries! docs.rs is a fantastic service to the community and I'm just glad you put up with all these corner cases. Versions are cheap and easy. :) 0.3.2 worked great. Thanks!

Hey @onur, new versions of rocket_codegen requires a newer version of nightly rustc. You can see the logs here: https://docs.rs/crate/hub-sdk/0.3.5/builds/73793

Do you know when a newer version of the compiler can be installed into the cratesfyi environment?

Thank you!

@jamesmunns sure I'll update rustc this evening.

Is the default-target option implemented yet, and if so, how do I specify it for my crates?

@onur Hey, sorry to bug, it looks like the latest build is still failing. Not sure if you got a chance to update.

Thanks again!

@jamesmunns I just started a build process to update rustc, it is usually taking 2-3 hours.

@jamesmunns I am having some trouble building rustc on OSX 10.6. Still working on it.

@onur could you add libparted-dev for libparted-sys to build? thanks :)

Hey @onur, not sure if you've had success building rustc. If you have, could you please re-trigger builds of the hub-sdk crate? Thank you!

@onur Hi,the crate influx_db_client v0.3.0 has no doc on crates, but I can build it with cargo doc on local. Is there anything wrong?

@onur Hello, the coinnect crate is not working anymore with docs.rs since version 0.53. You can see the issue here : https://github.com/hugues31/coinnect/issues/49. Anything I can do to fix this ? I tried to update some dependencies without success

@driftluo and @hugues31 rebuilt both crates.

IDK why incremental builds causing this problem. Rust suppose to recompile crates if it is required.

@onur Thank you, that was fast ;)

@onur Thank you.

@onur Just so you know, the problem is still there with the latest version of Coinnect (0.5.6)
Log:

error[E0460]: found possibly newer version of crate `idna` which `hyper` depends on
  --> .cargo/registry/src/github.com-1ecc6299db9ec823/coinnect-0.5.6/src/lib.rs:35:1
   |
35 | extern crate hyper;
   | ^^^^^^^^^^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: crate `idna` path #1: /home/cratesfyi/cratesfyi/debug/deps/libidna-61e19868261f71ed.rlib
   = note: crate `hyper` path #1: /home/cratesfyi/cratesfyi/debug/deps/libhyper-103a835b55757827.rlib

error: aborting due to previous error

Maybe you could disable incremental builds for specific crates ?

@onur Same problem with exonum crate:

   Compiling iron v0.5.1
     Running `rustc --crate-name iron .cargo/registry/src/github.com-1ecc6299db9ec823/iron-0.5.1/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' -C metadata=1cc541ec3996d7b1 -C extra-filename=-1cc541ec3996d7b1 --out-dir /home/cratesfyi/cratesfyi/debug/deps -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern num_cpus=/home/cratesfyi/cratesfyi/debug/deps/libnum_cpus-953d2648b0611ca8.rlib --extern-version num_cpus=num_cpus,1.7.0 --extern hyper=/home/cratesfyi/cratesfyi/debug/deps/libhyper-103a835b55757827.rlib --extern-version hyper=hyper,0.10.13 --extern lazy_static=/home/cratesfyi/cratesfyi/debug/deps/liblazy_static-5b85fba9276a8257.rlib --extern-version lazy_static=lazy_static,0.2.9 --extern conduit_mime_types=/home/cratesfyi/cratesfyi/debug/deps/libconduit_mime_types-dab415b3b481b36e.rlib --extern-version conduit_mime_types=conduit-mime-types,0.7.3 --extern typemap=/home/cratesfyi/cratesfyi/debug/deps/libtypemap-f950f1ce4f44c86e.rlib --extern-version typemap=typemap,0.3.3 --extern plugin=/home/cratesfyi/cratesfyi/debug/deps/libplugin-4615190dbca0445e.rlib --extern-version plugin=plugin,0.2.6 --extern log=/home/cratesfyi/cratesfyi/debug/deps/liblog-4cfe391024f1467d.rlib --extern-version log=log,0.3.8 --extern url=/home/cratesfyi/cratesfyi/debug/deps/liburl-8abcab8b95ef60ec.rlib --extern-version url=url,1.6.0 --extern modifier=/home/cratesfyi/cratesfyi/debug/deps/libmodifier-711dc1978f746917.rlib --extern-version modifier=modifier,0.1.0 --extern error=/home/cratesfyi/cratesfyi/debug/deps/liberror-b0aafa2e890bc18c.rlib --extern-version error=error,0.1.9 --cap-lints allow`
error[E0460]: found possibly newer version of crate `idna` which `hyper` depends on
  --> .cargo/registry/src/github.com-1ecc6299db9ec823/iron-0.5.1/src/lib.rs:66:1
   |
66 | extern crate hyper;
   | ^^^^^^^^^^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: crate `idna` path #1: /home/cratesfyi/cratesfyi/debug/deps/libidna-61e19868261f71ed.rlib
   = note: crate `hyper` path #1: /home/cratesfyi/cratesfyi/debug/deps/libhyper-103a835b55757827.rlib

error: aborting due to previous error

error: Could not compile `iron`.

Caused by:
  process didn't exit successfully: `rustc --crate-name iron .cargo/registry/src/github.com-1ecc6299db9ec823/iron-0.5.1/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg feature="default" -C metadata=1cc541ec3996d7b1 -C extra-filename=-1cc541ec3996d7b1 --out-dir /home/cratesfyi/cratesfyi/debug/deps -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern num_cpus=/home/cratesfyi/cratesfyi/debug/deps/libnum_cpus-953d2648b0611ca8.rlib --extern-version num_cpus=num_cpus,1.7.0 --extern hyper=/home/cratesfyi/cratesfyi/debug/deps/libhyper-103a835b55757827.rlib --extern-version hyper=hyper,0.10.13 --extern lazy_static=/home/cratesfyi/cratesfyi/debug/deps/liblazy_static-5b85fba9276a8257.rlib --extern-version lazy_static=lazy_static,0.2.9 --extern conduit_mime_types=/home/cratesfyi/cratesfyi/debug/deps/libconduit_mime_types-dab415b3b481b36e.rlib --extern-version conduit_mime_types=conduit-mime-types,0.7.3 --extern typemap=/home/cratesfyi/cratesfyi/debug/deps/libtypemap-f950f1ce4f44c86e.rlib --extern-version typemap=typemap,0.3.3 --extern plugin=/home/cratesfyi/cratesfyi/debug/deps/libplugin-4615190dbca0445e.rlib --extern-version plugin=plugin,0.2.6 --extern log=/home/cratesfyi/cratesfyi/debug/deps/liblog-4cfe391024f1467d.rlib --extern-version log=log,0.3.8 --extern url=/home/cratesfyi/cratesfyi/debug/deps/liburl-8abcab8b95ef60ec.rlib --extern-version url=url,1.6.0 --extern modifier=/home/cratesfyi/cratesfyi/debug/deps/libmodifier-711dc1978f746917.rlib --extern-version modifier=modifier,0.1.0 --extern error=/home/cratesfyi/cratesfyi/debug/deps/liberror-b0aafa2e890bc18c.rlib --extern-version error=error,0.1.9 --cap-lints allow` (exit code: 101)
thread 'main' panicked at 'build failed', src/bin/cratesfyi.rs:142

blake2_c is triggering some kind of compiler panic: https://docs.rs/crate/blake2_c/0.1.0/builds/75548

     Running `rustdoc --crate-name blake2_c .cargo/registry/src/github.com-1ecc6299db9ec823/blake2_c-0.1.0/src/lib.rs -o /home/cratesfyi/cratesfyi/doc -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern arrayvec=/home/cratesfyi/cratesfyi/debug/deps/libarrayvec-e69a739a6c34cb30.rlib --extern-version arrayvec=arrayvec,0.4.6 --extern constant_time_eq=/home/cratesfyi/cratesfyi/debug/deps/libconstant_time_eq-2500fa3ec1dc417c.rlib --extern-version constant_time_eq=constant_time_eq,0.1.3`
error: internal compiler error: broken MIR in NodeId(2702) (Terminator { source_info: SourceInfo { span: .cargo/registry/src/github.com-1ecc6299db9ec823/blake2_c-0.1.0/src/lib.rs:244:43: 244:48, scope: scope2 }, kind: _15 = const std::ops::DerefMut::deref_mut(_16) -> [return: bb5, unwind: bb4] }): call dest mismatch (&mut [std::os::raw::c_void] <- &mut [_]): Sorts(ExpectedFound { expected: std::os::raw::c_void, found: u8 })
   --> .cargo/registry/src/github.com-1ecc6299db9ec823/blake2_c-0.1.0/src/lib.rs:244:43
    |
244 |                   $finalize_fn(&mut self.0, bytes.as_mut_ptr() as *mut c_void, bytes.len());
    |                                             ^^^^^
...
291 | / blake2_impl! {
292 | |     blake2b,
293 | |     sys::blake2b_constant::BLAKE2B_BLOCKBYTES,
294 | |     sys::blake2b_constant::BLAKE2B_OUTBYTES,
...   |
305 | |     u32,
306 | | }
    | |_- in this macro invocation

note: the compiler unexpectedly panicked. this is a bug.

I'm not able to repro this with rustup run [toolchain] cargo doc --open for any of stable/beta/nightly. Is there any other command I should try?

Edit: Seems to be a consistent failure: https://docs.rs/crate/blake2_c/0.1.1/builds/75852

fitsio is failing to build due to a missing dependency: libcfitsio3-dev. If it's not too much trouble, could this package be installed?

@mindriot101 fixed fitsio.

@oconnor663 I believe current rust compiler that docs.rs uses cannot compile blake2_c. Upgrading rustc should work, I am still working on it. I got a new OSX machine to build rustc.

@onur thanks! If I can help by trying any older versions of the compiler, or building anything myself on Linux, let me know.

@oconnor663 thanks! Linux and Windows is fine, only OSX caused some problems in past weeks because of my old machine. I'll hopefully fix it in few days.

Crate matches reports it has not managed to build the docs: https://docs.rs/crate/matches/0.1.6 but the docs are there, just a bit cumbersome to reach: https://docs.rs/matches/0.1.6/matches/

Does anybody know how to fix this problem?

$ rustc --version
rustc 1.22.0-dev (b1cfd1750 2017-09-21)
$ cratesfyi --version
cratesfyi 0.4.2 (13da7b2 2017-10-12)
$ cratesfyi ...
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading netlib-src v0.7.2
       Fresh cc v1.0.3
       Fresh cmake v0.1.28
   Compiling netlib-src v0.7.2
     Running `rustc --crate-name build_script_build .cargo/registry/src/github.com-1ecc6299db9ec823/netlib-src-0.7.2/build.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 --cfg 'feature="cblas"' --cfg 'feature="default"' --cfg 'feature="lapacke"' -C metadata=333f8f516635ae85 -C extra-filename=-333f8f516635ae85 --out-dir /home/cratesfyi/cratesfyi/debug/build/netlib-src-333f8f516635ae85 -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern cmake=/home/cratesfyi/cratesfyi/debug/deps/libcmake-9a3c8072c376ac95.rlib --extern-version cmake=cmake,0.1.28 --cap-lints allow`
     Running `/home/cratesfyi/cratesfyi/debug/build/netlib-src-333f8f516635ae85/build-script-build`
thread 'main' panicked at 'Human(
    failed to run custom build command for `netlib-src v0.7.2`
    process didn't exit successfully: `/home/cratesfyi/cratesfyi/debug/build/netlib-src-333f8f516635ae85/build-script-build` (exit code: 101)
    --- stdout
    running: "cmake" "/home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/netlib-src-0.7.2/source" "-DBUILD_TESTING=OFF" "-DBUILD_SHARED_LIBS=ON" "-DCBLAS=ON" "-DLAPACKE_WITH_TMG=ON" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_PREFIX=/home/cratesfyi/cratesfyi/debug/build/netlib-src-884f1319435f48b3/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_BUILD_TYPE=Debug"
    -- The Fortran compiler identification is unknown
    -- Configuring incomplete, errors occurred!
    See also "/home/cratesfyi/cratesfyi/debug/build/netlib-src-884f1319435f48b3/out/build/CMakeFiles/CMakeOutput.log".
    See also "/home/cratesfyi/cratesfyi/debug/build/netlib-src-884f1319435f48b3/out/build/CMakeFiles/CMakeError.log".

    --- stderr
    CMake Error at CMakeLists.txt:11 (project):
      No CMAKE_Fortran_COMPILER could be found.

      Tell CMake where to find the compiler by setting either the environment
      variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
      path to the compiler, or to the compiler name if it is in the PATH.


    thread 'main' panicked at '
    command did not execute successfully, got: exit code: 1

    build script failed, must exit now', .cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.28/src/lib.rs:631:4
    note: Run with `RUST_BACKTRACE=1` for a backtrace.

)', src/bin/cratesfyi.rs:142
note: Run with `RUST_BACKTRACE=1` for a backtrace.

@IvanUkhov fixed. Are there any other crates affected by this?

@onur let me know if I should push a version bump for blake2_c to force a rebuild of the docs?

@onur, not that I know of. Thanks a lot!

Hi @onur, do you know what the problem is with the Coinnect crate ? Do I need to bump the version ?

@onur thanks for fixing fitsio!

Hey @onur, could you please retrigger the build for hub-sdk? I think you've fixed some stuff since the last build attempt: https://docs.rs/crate/hub-sdk/0.4.1/builds/74002

mp4parse_capi fails to build. I think this cargo workspace issue will fix it.

jni 0.9.0 fails to build, and the problem is in the usage of the ? operator with Option<...> types.

Try is implemented for Option in Rust 1.22.0. Maybe the 1.22.0-dev version docs.rs is using doesn't have the patch?

@fpoli You should be able to reproduce with rustup default 1.21.0 which I'd expect to behave similarly. But it looks like docs.rs also needs to update. The current stable release is 1.23.0.

Hi @rillian, thanks for reporting. I have some troubles updating rustc on docs.rs but I'll definitely solve this issue this weekend.

pest_derive fails to build docs because it requires the newest stable rustc. (1.23)

Likewise, dependencies of pest itself (see latest comrak build log).

Hello,
I'm having some issues getting the documentation for counting-networks 0.1.x to build. I'm using some nightly features, specifically allocator_api, pointer_methods, attr_literals, and shared. I have these enabled in a #![feature(...)] tag at the top of my lib.rs.

However, the build logs on docs.rs are displaying two main errors:

$ cratesfyi ...
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading counting-networks v0.1.2
 Documenting counting-networks v0.1.2
     Running `rustdoc --crate-name counting_networks .cargo/registry/src/github.com-1ecc6299db9ec823/counting-networks-0.1.2/src/lib.rs -o /home/cratesfyi/cratesfyi/doc -L dependency=/home/cratesfyi/cratesfyi/debug/deps`
error[E0432]: unresolved import `std::ptr::NonNull`
 --> .cargo/registry/src/github.com-1ecc6299db9ec823/counting-networks-0.1.2/src/networks/bitonic.rs:2:5
  |
2 | use std::ptr::NonNull;
  |     ^^^^^^^^^^^^^^^^^ no `NonNull` in `ptr`

error: the struct `#[repr(align(u16))]` attribute is experimental (see issue #33626)
  --> .cargo/registry/src/github.com-1ecc6299db9ec823/counting-networks-0.1.2/src/networks/bitonic.rs:87:1
   |
87 | #[repr(align(64))]
   | ^^^^^^^^^^^^^^^^^^
   |
   = help: add #![feature(repr_align)] to the crate attributes to enable

error: aborting due to 2 previous errors

The repr_align feature is supposed to be stable on the latest nightly releases. The std::ptr::NonNull is related to the shared feature in that std::ptr::Shared was renamed to NonNull, so I assumed that the shared feature gate would still be valid, though I could be wrong. If you have any ideas to what I should change or add, here is the source code.

EDIT: actually after looking at the Shared renamed to NonNull PR, it was also stabilized, so the shared feature gate shouldn't be needed.

Thanks so much,
Declan

@declanvk: Looks like my crate (https://docs.rs/crate/apint/0.0.0-alpha.9) is missing docs because of the same reason. Thank you for investigating!

I am still working on updating rustc on docs.rs. This rust-lang/rust#48013 is finally approved, after this gets merged I'll be able to update rustc on docs.rs and rebuild every crate that has failed since last rustc update.

my "slime" crate docs build fails too because of pest

@onur, could you please rebuild pest_derive and all its dependent crates?

tf-rs crate ver 0.0.2 failed to build docs.

It reports ? operator not implemented for Option while building a dependency, but is using rustc 1.22 which should be fine. Furthermore the dependency that is failing has it's docs built (!) just fine.

Report: https://docs.rs/crate/tf-rs/0.0.2/builds/85672

@onur I see that rustc was updated, but pest_derive still fails to build. Any updates?

My crate, apt-pkg-native, fails to build as it needs libapt-pkg-dev installed on the machine.

As the host system is Debian, it could pick up the apt: lines from .travis.yml, perhaps? They maintain a package whitelist to protect the integrity of the host.

That, or I could fix the crate to generate docs under some profile!

Question: would it be possible to add maybe a button to the UI that can facilitate rebuilding broken packages? Essentially, if 1. the version of rustc for docs.rs has been updated and 2. the package failed to compile, then you can click the button to try to rebuild the crate docs. I think some amount of rate-limiting would be necessary but overall I think it's a good change, so that people can just ask to bump rustc and that they can rebuild the docs themselves.

My apint crate does not have documentation for its newest version. Builds logs indicate that docs.rs tried to build it with an old Rust 1.22 compiler version. Could you please rebuild the docs for it? Also the proposal for the rebuild button would be very nice in those cases. :]

tsunami fails to build (docs.rs link).

fui build fails

Hi guys, we are still working to update rustc on docs.cs and we made some progress to fix theme-picker breakage in here: https://github.com/rust-lang/rust/pull/48511

I believe I'll be able to rebuild every crate in matter of few days.

Latest version of rustc (1.26.0-dev (5c1d29af0 2018-03-03)) is finally up and running on docs.rs. Some missing docs fixes reported in this thread:

And now docs.rs is building every crate that have failed to build since last rustc update.

https://docs.rs/crate/aesni/0.3.1

Update to the latest Nightly should fix the issue.

@newpavlov, sidebar also have some issues waiting few PR's to merge before update

https://docs.rs/rahashmap/0.2.0 (Needs latest nightly)

The yubihsm crate is not building since it uses (previously reported) aesni crate

@newpavlov @fintelia @tarcieri new rust fixed all reported crates.

@onur fantastic! Thanks!

Hi, I got a failure here.
From what I see, the issue comes from the build script of the j4rs crate, because there is a requirement for the $JAVA_HOME to exist.

Is Java present in the docs building configuration? If not, can it be?

Hi there, I got a failure at sgx_tstd.
I tried the latest cratesfyi and it's ok. So I think you guys have fixed the problem.
Failure exists on crates at sgx_serialize, sgx_tunittest and sgx_rand because they depend on sgx_tstd.

This would be a giant change, but would it be possible to rebuild all crates so that the addition of themes to rustdoc works across the entire site?

My crate libcdio-sys fails to build because the packages libcdio-dev, libiso9660-dev and libudf-dev are missing.

I'm having an issue building the documentation for my crate test-data-generation v0.0.2.
I'm not sure what the message about a missing feature "doc" means.

Build #94551 2018-04-05T02:17:34+02:00

$ rustc --version
rustc 1.26.0-dev (0eb87c9bf 2018-03-16)
$ cratesfyi --version
cratesfyi 0.5.0 (579f83b 2018-03-05)
$ cratesfyi ...
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading test-data-generation v0.0.2
thread 'main' panicked at 'Error(
    CargoError(
        Package `test-data-generation v0.0.2` does not have these features: `doc`
    ),
    State {
        next_error: None,
        backtrace: None
    }
)', src/bin/cratesfyi.rs:142:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.

My docs are failing to build because the rustc version is too old 😢 any chance of an update? https://docs.rs/crate/pin-rc/0.1.0

Any idea how to get the docs to build for this crate? https://docs.rs/crate/web-view/

@dsietz [package.metadata.docs.rs] in test-data-generation's Cargo.toml is causing this issue. Docs.rs is trying to build doc feature and since your crate doesn't have this feature build is failing. Removing docs.rs metadata from your Cargo.toml should work.

@gmes installed missing dependencies, libcdio-sys is building fine now.

@Boscop web-view is fixed!

@onur Thanks for catching that. I completely missed the fact that I had that in there. You saved me a world of time and frustration.

Thank you very much @onur!

Docs for winapi should be built for windows, otherwise it's not useful:
https://docs.rs/winapi/0.3.4/winapi/
If it's not possible, the page should link to this instead:
https://docs.rs/winapi/*/x86_64-pc-windows-msvc/winapi/index.html

https://docs.rs/crate/rocket_static_fs/0.1.3 fails to build, because of an old rustc nightly version.

See log: https://docs.rs/crate/rocket_static_fs/0.1.3/builds/95565

https://docs.rs/crate/rexsgdata/0.1.9/builds/95929 - looks like it fails to build due to oldish rustc used for generating the docs.

It appears rustc 1.26.0-dev (0eb87c9bf 2018-03-16) is in use.
Newer rustc 1.26.0-beta.3 (8a75d2b50 2018-04-08) should build it without problems

Is there a way to queue a new build from the same crate version? The build for one of my crates failed because of outdated dependencies (proc_macro2) which i guess should now be updated?
Edit: https://docs.rs/crate/value_from_type_macros/1.0.5/builds/94528

https://docs.rs/crate/parquet/0.2.0/builds/97194 - similarly also failed due to the need of nightly rustc.

https://docs.rs/asciimath https://crates.io/crates/asciimath docs for last two versions have gotten ignored for some reason. No build errors seem to be present either.

Anyone know why this happened? Thank you.

@budziq this has been fixed; we just didn't put out a new release yet (this is a pre-release). You probably want the Rand 0.4.2 docs anyway.

https://docs.rs/programinduction/0.6.0 fails because it uses impl Trait which was just made stable in 1.26. The docs build thinks #![feature(conservative_impl_trait)] is required, but that's no longer the case.

https://docs.rs/crate/num-traits/0.2.3 fails because I set it for --all-features, which needs stable Rust 1.26 for 128-bit integer support.

Docs builds use a locally-modified rustc from source, which for both of these is dated 2018-03-16. That's probably before the stabilization of either of these features landed.

Jetscii 0.4.0 failed to build, but it compiles successfully locally with the current beta (rustc 1.27.0-beta.2)

ring 0.13.0-alpha2 fails to build but it compiles successfully locally with current stable 1.26

Yet another build failed because of a month old rustc:

https://docs.rs/crate/randomize/0.890.0/builds/99563

Failing because of rust version:
(It requires stable Rust 1.26)
https://docs.rs/crate/apint/0.2.0/builds/99880

clacks_tl_codegen is failing to built extprim, but the same version of extprim built successfully with the same versions of rustc/cratesfyi. Not sure if this is a weird ephemeral thing or a broken transitive dep or feature-flag related?

https://docs.rs/crate/bf/0.4.6 fails to build because https://docs.rs/crate/dynasm/0.2.1 fails to build. It requires a more recent nightly rustc.

Amethyst 0.7.0 failed to build

https://docs.rs/crate/amethyst/0.7.0/builds/100225

Cause of failure is unclear, we can't reproduce this locally even after doing a cargo update. Can we rebuild and see if it happens again?

@xaeroxe the 1.26.0-dev version of rustc is not the full normal 1.26 rustc. Check the past week or two of posts here, we all have this problem

Also affected here

(same issue as above comments)

maud 0.17.5 failed to build.

I released that version in response to rust-lang/rust#50473, so a rustc update should fix it.

snow 0.1.11 failed to build, I'm assuming also because of the differences in 1.26.0-dev vs. the normal stable, and rustup run stable -- cargo doc --features ring-resolver,hacl-resolver works on my end.

quicksilver v0.2.1 failed to build, is that related to this issue?

Recent versions of Serde which use i128 when built with Rust 1.26+, are failing to build.
https://docs.rs/crate/serde/1.0.62/builds/101112

Arc Reactor 0.1.7 docs are failing because of impl Trait in return position.

I believe impl trait has been stabilized?

https://docs.rs/crate/arc-reactor/0.1.7/builds/100736

a2 and web-push docs are failing because of ring 0.13.0-alpha4:

https://docs.rs/crate/web-push/0.4.0/builds/101949

I can build these on travis and on my machine.

proptest 0.7.1 doesn't appear to have been picked up at all; I don't see any attempt to build it.

https://docs.rs/crate/proptest/
https://docs.rs/crate/proptest/0.7.1/builds

docs.rs failed to build generator_ext-0.1.2
https://docs.rs/crate/generator_ext/0.1.2

Recent versions of actix-web are failing to build

https://docs.rs/crate/actix-web/0.6.13/builds/105314

In a new version of aesni crate I've used the following lines in the Cargo.toml as was recommended here:

[package.metadata.docs.rs]
rustc-args = [ "-C target-feature=+aes" ]

But crate fails to build. Any recommendations?

UPD: The following config fixed the problem:

[package.metadata.docs.rs]
rustc-args = ["-C", "target-feature=+aes"]
rustdoc-args = ["-C", "target-feature=+aes"]

actix-web build fails with following error and it is not related to actix-web itself.

error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  |
  = help: add #![feature(extern_prelude)] to the crate attributes to enable

error: Could not document `h2`.

The latest h2 crate failed to build as well: https://docs.rs/crate/h2/0.1.10/builds/105915

 Documenting h2 v0.1.10
     Running `rustdoc --crate-name h2 .cargo/registry/src/github.com-1ecc6299db9ec823/h2-0.1.10/src/lib.rs -o /home/cratesfyi/cratesfyi/doc -Z unstable-options --resource-suffix -20180602-1.28.0-dev-b9bf4f162 -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern fnv=/home/cratesfyi/cratesfyi/debug/deps/libfnv-faa257ace9f05d30.rlib --extern-version fnv=fnv,1.0.6 --extern string=/home/cratesfyi/cratesfyi/debug/deps/libstring-2b689272e59a6f07.rlib --extern-version string=string,0.1.0 --extern http=/home/cratesfyi/cratesfyi/debug/deps/libhttp-b8f0bee3b403a7cb.rlib --extern-version http=http,0.1.6 --extern slab=/home/cratesfyi/cratesfyi/debug/deps/libslab-81a5dc5c0e5d6600.rlib --extern-version slab=slab,0.4.0 --extern log=/home/cratesfyi/cratesfyi/debug/deps/liblog-f60611c4b4a0a67b.rlib --extern-version log=log,0.4.2 --extern bytes=/home/cratesfyi/cratesfyi/debug/deps/libbytes-9767ad855bd0682b.rlib --extern-version bytes=bytes,0.4.8 --extern byteorder=/home/cratesfyi/cratesfyi/debug/deps/libbyteorder-9912b24f648af35d.rlib --extern-version byteorder=byteorder,1.2.3 --extern futures=/home/cratesfyi/cratesfyi/debug/deps/libfutures-598c411fba99bc6b.rlib --extern-version futures=futures,0.1.21 --extern indexmap=/home/cratesfyi/cratesfyi/debug/deps/libindexmap-f41d1eed9e1ac11e.rlib --extern-version indexmap=indexmap,1.0.1 --extern tokio_io=/home/cratesfyi/cratesfyi/debug/deps/libtokio_io-25b4cc70b7f76370.rlib --extern-version tokio_io=tokio-io,0.1.7`
warning: [u8] cannot be resolved, ignoring it...

warning: [cfg] cannot be resolved, ignoring it...

warning: [Debug] cannot be resolved, ignoring it...

error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  |
  = help: add #![feature(extern_prelude)] to the crate attributes to enable

thread 'main' panicked at 'Error(
    CargoError(
        ChainedError {
            error: Could not document `h2`.,
            cause: process didn't exit successfully: `rustdoc --crate-name h2 .cargo/registry/src/github.com-1ecc6299db9ec823/h2-0.1.10/src/lib.rs -o /home/cratesfyi/cratesfyi/doc -Z unstable-options --resource-suffix -20180602-1.28.0-dev-b9bf4f162 -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern fnv=/home/cratesfyi/cratesfyi/debug/deps/libfnv-faa257ace9f05d30.rlib --extern-version fnv=fnv,1.0.6 --extern string=/home/cratesfyi/cratesfyi/debug/deps/libstring-2b689272e59a6f07.rlib --extern-version string=string,0.1.0 --extern http=/home/cratesfyi/cratesfyi/debug/deps/libhttp-b8f0bee3b403a7cb.rlib --extern-version http=http,0.1.6 --extern slab=/home/cratesfyi/cratesfyi/debug/deps/libslab-81a5dc5c0e5d6600.rlib --extern-version slab=slab,0.4.0 --extern log=/home/cratesfyi/cratesfyi/debug/deps/liblog-f60611c4b4a0a67b.rlib --extern-version log=log,0.4.2 --extern bytes=/home/cratesfyi/cratesfyi/debug/deps/libbytes-9767ad855bd0682b.rlib --extern-version bytes=bytes,0.4.8 --extern byteorder=/home/cratesfyi/cratesfyi/debug/deps/libbyteorder-9912b24f648af35d.rlib --extern-version byteorder=byteorder,1.2.3 --extern futures=/home/cratesfyi/cratesfyi/debug/deps/libfutures-598c411fba99bc6b.rlib --extern-version futures=futures,0.1.21 --extern indexmap=/home/cratesfyi/cratesfyi/debug/deps/libindexmap-f41d1eed9e1ac11e.rlib --extern-version indexmap=indexmap,1.0.1 --extern tokio_io=/home/cratesfyi/cratesfyi/debug/deps/libtokio_io-25b4cc70b7f76370.rlib --extern-version tokio_io=tokio-io,0.1.7` (exit code: 101)
        }
    ),
    State {
        next_error: None,
        backtrace: None
    }
)', src/bin/cratesfyi.rs:142:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.

https://docs.rs/erlang_nif-sys/0.6.4/erlang_nif_sys/ needs Erlang OTP 21 to build all of its documentation. OTP 21-specific functions are currently missing.

Greetings,

My crate eventstore failed to build because it needs protoc in the $PATH

thread 'main' panicked at 'Error(
    CargoError(
        Human(
            failed to run custom build command for `eventstore v0.1.0`
            process didn't exit successfully: `/home/cratesfyi/cratesfyi/debug/build/eventstore-7433c00d704cbd30/build-script-build` (exit code: 101)
            --- stderr
            thread 'main' panicked at 'protoc: Custom { kind: NotFound, error: StringError("failed to spawn `\"protoc\" \"--version\"`: No such file or directory (os error 2)") }', libcore/result.rs:945:5
            note: Run with `RUST_BACKTRACE=1` for a backtrace.

        )
    ),
    State {
        next_error: None,
        backtrace: None
    }
)', src/bin/cratesfyi.rs:142:13

https://docs.rs/crate/eventstore/0.1.0/builds/106153

Thanks for your time.

yew fails to build because it needs the PATH_SEPARATOR environment variable. See https://docs.rs/crate/yew/0.4.0/builds/103459

Looks like diesel docs aren't building since 1.3.0 (now 1.3.2) https://docs.rs/crate/diesel/1.3.0 https://docs.rs/crate/diesel/1.3.0/builds/104142

diesel docs

Diesel also hosts their own docs.

The recent nighly stabilizations break all crates using proc macros that now migrated to use_extern_macros, e.g. pyo3 and wasm-bindgen.

Seconding what @konstin reported regarding proc macros: need the latest nightly (1.29) for crates such as azure-functions and azure-functions-codegen that have migrated to use_extern_macros.

Well my crate got no docs, sad https://docs.rs/crate/yukikaze/0.0.1/builds

Error:

error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  |
  = help: add #![feature(extern_prelude)] to the crate attributes to enable

But I'm not sure from where it is coming from

@seanmonstar reqwest also fails with the error[E0658]: access to extern crates through prelude is experimental (see issue #44660) error: https://docs.rs/crate/reqwest/0.8.7/builds/110715.

Failed to build https://docs.rs/crate/uvc-sys/0.1.0

The build fails due to libuvc not being installed

https://crates.io/crates/h2 also fails to build with the same error as in previous comments:

error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  |
  = help: add #![feature(extern_prelude)] to the crate attributes to enable

thread 'main' panicked at 'Error(
    CargoError(
        ChainedError {
            error: Could not document `h2`.,
            cause: process didn't exit successfully: `rustdoc --crate-name h2 .cargo/registry/src/github.com-1ecc6299db9ec823/h2-0.1.12/src/lib.rs -o /home/cratesfyi/cratesfyi/doc -Z unstable-options --resource-suffix -20180602-1.28.0-dev-b9bf4f162 -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern fnv=/home/cratesfyi/cratesfyi/debug/deps/libfnv-faa257ace9f05d30.rlib --extern-version fnv=fnv,1.0.6 --extern tokio_io=/home/cratesfyi/cratesfyi/debug/deps/libtokio_io-25b4cc70b7f76370.rlib --extern-version tokio_io=tokio-io,0.1.7 --extern http=/home/cratesfyi/cratesfyi/debug/deps/libhttp-07e15073e011d227.rlib --extern-version http=http,0.1.10 --extern bytes=/home/cratesfyi/cratesfyi/debug/deps/libbytes-996bdd1cd39c08a8.rlib --extern-version bytes=bytes,0.4.9 --extern string=/home/cratesfyi/cratesfyi/debug/deps/libstring-2b2234c5d67ab57d.rlib --extern-version string=string,0.1.1 --extern indexmap=/home/cratesfyi/cratesfyi/debug/deps/libindexmap-f41d1eed9e1ac11e.rlib --extern-version indexmap=indexmap,1.0.1 --extern byteorder=/home/cratesfyi/cratesfyi/debug/deps/libbyteorder-35abf1ff955f78f5.rlib --extern-version byteorder=byteorder,1.2.4 --extern log=/home/cratesfyi/cratesfyi/debug/deps/liblog-c3ec1d3c60904ac4.rlib --extern-version log=log,0.4.3 --extern slab=/home/cratesfyi/cratesfyi/debug/deps/libslab-8bdcdf1795930a41.rlib --extern-version slab=slab,0.4.1 --extern futures=/home/cratesfyi/cratesfyi/debug/deps/libfutures-7c92a300de6e1cf8.rlib --extern-version futures=futures,0.1.23` (exit code: 101)
        }
    ),
    State {
        next_error: None,
        backtrace: None
    }
)', src/bin/cratesfyi.rs:142:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.

proptest versions newer than 0.7.0 fail to be added to the database because the doc string used as the long description is longer than 51,200 bytes. (It's 53,518 bytes as of me writing this.)

reqwest 0.8.8 is also failing to build, looks like the same error as 0.8.7
https://docs.rs/crate/reqwest/0.8.8/builds/113111

graphannis 0.8.1 does not build because docs.rs uses the rust compiler 1.28.0-dev version instead of the released stable on. The compiler complains the global_allocator feature is not stabilized yet, which has been stabilized with 1.28 of rustc

https://docs.rs/crate/graphannis/0.8.1

https://docs.rs/crate/graphannis/0.8.1/builds/112947

From https://docs.rs/crate/cryptonight-rs/0.1.0/builds/113508:

running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-m64" "-I" "src/vendor/crypto" "-I" "src/vendor/common" "-Wall" "-Wextra" "-maes" "-Ofast" "-fexceptions" "-o" "/home/cratesfyi/cratesfyi/debug/build/cryptonight-rs-2ca67d4bbcaa14da/out/src/vendor/chacha.o" "-c" "src/vendor/chacha.c"
cargo:warning=In file included from src/vendor/chacha.c:15:0:
cargo:warning=src/vendor/warnings.h:14:44: fatal error: boost/preprocessor/stringize.hpp: No such file or directory
cargo:warning= #include <boost/preprocessor/stringize.hpp>
cargo:warning=                                            ^
cargo:warning=compilation terminated.

https://docs.rs/crate/voluntary-servitude/1.0.2

Complains about using global_allocator, but it's stable.

im 12.0.0 also isn't building because of a feature that's just been stabilised in rustc 1.28: https://docs.rs/crate/im/12.0.0/builds/114882

Same issue as some people above (access to extern crates through prelude is experimental (see issue #44660)): https://docs.rs/crate/dolphin/0.1.0-alpha.1/builds/115238

I've got build errors due to using the new module system of the 2018 edition, see https://github.com/onur/docs.rs/issues/231

Another extern_prelude error. Don't know where it's coming from.

I can't reproduce this locally, with any of the Rust versions I've tried.

    --- snip ---
error[E0658]: access to extern crates through prelude is experimental (see issue #44660)
  |
  = help: add #![feature(extern_prelude)] to the crate attributes to enable
    --- snip ---

https://docs.rs/crate/chbs/0.0.5/builds/115585


Edit: fixed it by removing these external links: gitlab.com/timvisee/chbs#6dda79e

For anyone seeing failures from features that have been stabilized -- usually those can be fixed like this.

# in Cargo.toml

[package.metadata.docs.rs]
rustdoc-args = ["--cfg", "docs_rs_workaround"]
// in src/lib.rs

#![cfg_attr(docs_rs_workaround, feature(/* whichever features */))]

https://docs.rs/crate/dumb-exec/0.0.4/builds/116783

Local builds of the docs work fine and the issue seems to entirely be at the fault of the futures library, but it was fixed in v0.3.0-alpha.5.

The same error occurs in the previous version of my crate and 0.0.4 was pushed specifically to fix it, which it failed to do.

Latest version of vergen seems to be missing: https://docs.rs/vergen/ goes 404.

Also getting errors due to features stabilized in 1.28

https://docs.rs/crate/qmetaobject/

A custom build command failed.

Is it possible to update to the current libsodium-version (1.0.16)? 1.0.11 is pretty old and a lot has changed since then... And my crate won't build with 1.0.11 😇

https://docs.rs/crate/rusttype/0.7.2

Plus many crates that depend on rusttype.

https://docs.rs/crate/null-terminated/0.3.4

works on nightly-2018-09-25

This crate compiles under nightly rustc 1.30.0-nightly (fc81e3624 2018-09-07) but gives an error about prelude access: https://docs.rs/crate/rsevents-extra

https://docs.rs/crate/ocaml/0.5.0/

It builds using 1.28, but it looks like you're using a 1.28 pre-release, which doesn't support #repr(transparent)

https://docs.rs/crate/rkv/0.5.1

rkv depends on ordered-float ^1.0, which uses #[repr(transparent)]. Other crates that depend on ordered-float ^1 and whose docs are also missing from docs.rs (presumably for the same reason, although I haven't checked all their build logs):

https://crates.io/crates/exponential-decay-histogram
https://crates.io/crates/glyph_brush_layout
https://crates.io/crates/glyph_brush
https://crates.io/crates/ledb
https://crates.io/crates/livesplit-core
https://crates.io/crates/rusttype

Plus any transitive dependencies, like those for rusttype, as @jthile mentioned above.

The build error of https://docs.rs/crate/secp256k1/0.11.2 seems to possibly be a docs.rs bug.

It adds '--features "rand serde"' to the command arguments. Note the single quotes around it.

... --resource-suffix -20180602-1.28.0-dev-b9bf4f162 '--features "rand serde"' -L dependency= ...

This build error https://docs.rs/crate/kg-symbol/0.1.3/builds/119672 stems from the outdated rustc version used (1.28), I believe. Current nightly is rustc 1.31.0-nightly (8c4ad4e9e 2018-10-04) and it features, among other things, a new allocator_api, which I am using in kg-symbol crate. Could You please update rustc in Your build environment?
Thanks,
Jakub

The winlog crate won't doc because its winreg dependency fails to build. I seems that winreg fails to build because it requires Windows APIs but docs.rs is compiling it on non-Windows.

I was hoping that adding a

[package.metadata.docs.rs]
default-target = "x86_64-pc-windows-msvc"

to the winlog project would help fix this but it doesn't seem to. Would it help if the default-target was added to Cargo.toml in the winreg crate?

The arduino-leonardo crate build fails with a SIGSEGV:

cause: process didn't exit successfully: `rustc [...]` (signal: 11, SIGSEGV: invalid memory reference)

Interestingly, the error occurs when trying to build the atmega32u4-hal crate which by itself seems to build: atmega32u4-hal

I guess this might have to do with this crate being for a different architecture but even in that case I think the compiler should never segfault ...

I can build the docs perfectly fine using nightly:

rustup run nightly cargo doc --features docs

failed build

Protobuf compiler binaryprotoc not present, which prevents compilation of any crates that perform protobuf compilation.

error: Could not compile `prost-build`.,
            cause: process didn't exit successfully: `rustc --crate-name prost_build .cargo/registry/src/github.com-1ecc6299db9ec823/prost-build-0.4.0/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=3d80160d4018704d -C extra-filename=-3d80160d4018704d --out-dir /home/cratesfyi/cratesfyi/debug/deps -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern prost_types=/home/cratesfyi/cratesfyi/debug/deps/libprost_types-2eebb55e3c7c9fa2.rlib --extern-version prost_types=prost-types,0.4.0 --extern log=/home/cratesfyi/cratesfyi/debug/deps/liblog-f5bbe4c1999a96be.rlib --extern-version log=log,0.4.5 --extern heck=/home/cratesfyi/cratesfyi/debug/deps/libheck-0f6a03313005e29d.rlib --extern-version heck=heck,0.3.0 --extern multimap=/home/cratesfyi/cratesfyi/debug/deps/libmultimap-8b7db1efe7b5bf95.rlib --extern-version multimap=multimap,0.4.0 --extern prost=/home/cratesfyi/cratesfyi/debug/deps/libprost-424fe3c8f8f31be6.rlib --extern-version prost=prost,0.4.0 --extern itertools=/home/cratesfyi/cratesfyi/debug/deps/libitertools-a15b6570ce0da9e4.rlib --extern-version itertools=itertools,0.7.8 --extern env_logger=/home/cratesfyi/cratesfyi/debug/deps/libenv_logger-1c29b4690a73ddc1.rlib --extern-version env_logger=env_logger,0.5.13 --extern tempdir=/home/cratesfyi/cratesfyi/debug/deps/libtempdir-c01c5b42e42ed614.rlib --extern-version tempdir=tempdir,0.3.7 --extern bytes=/home/cratesfyi/cratesfyi/debug/deps/libbytes-2d5abb6d0f9164d7.rlib --extern-version bytes=bytes,0.4.10 --extern petgraph=/home/cratesfyi/cratesfyi/debug/deps/libpetgraph-8a6f52c69816a95c.rlib --extern-version petgraph=petgraph,0.4.13 --cap-lints allow` (exit code: 101)

The build appears to be using an outdated version of rust - 1.28. Are there any plans to upgrade to the current one?

Build #120313 2018-10-09T22:46:01+02:00

$ rustc --version
rustc 1.28.0-dev (b9bf4f162 2018-06-02)
$ cratesfyi --version
cratesfyi 0.5.0 (579f83b 2018-03-05)
... ... ...

https://docs.rs/crate/parsing-tech/0.1.2/builds/121420

Looks like trim_start is only available in Rust 1.30, while docs.rs is still on 1.28

@ZerothLaw
Thanks
I will use github pages for api docs for now

Looks like it doesn't work with crates using the cargo feature rename-dependency.

https://docs.rs/crate/tarpc/0.13.0/builds/121972

I am getting a transparent error while building the docs. But I was able to get Travis build and run locally. It might be related to rustc version.

Fresh jpeg-decoder v0.1.15 error[E0658]: the#[repr(transparent)]attribute is experimental (see issue #43036) --> .cargo/registry/src/github.com-1ecc6299db9ec823/ordered-float-1.0.1/src/lib.rs:44:1 |

Thanks to https://github.com/onur/docs.rs/pull/243, the rustc on docs.rs has been updated to 1.31.0-nightly (78ff609d7 2018-10-19). New crate releases should build with this rust compiler, though releases that previously failed have not been queued up to rebuild yet.

https://docs.rs/mio-st redirects to https://docs.rs/mio-st/0.1.0/mio_st/, but says "The requested resource does not exist". Follow up from #233.

My crate has not been rebuilt https://docs.rs/crate/livesplit-core/0.10.0

@CryZe livesplit-core have been rebuilt now.

Any chance rusttype, glyph_brush_layout, glyph_brush & gfx_glyph will be rebuilt?

Update: They have all been rebuilt now, thanks!

@onur Thank you very much ❤️

Please rebuild https://docs.rs/crate/reffers/0.5.0/builds - thanks!

Edit: never mind, uploaded 0.5.1 instead

crates based on zmq-sys built fine a couple days ago, but after releasing some updates around 12 hours ago, it seems docs.rs no longer has libzmq installed to build these packages.

https://docs.rs/crate/tokio-zmq/0.7.0/builds/126983

We had to update the minimum nightly in pyo3 to 2018-11-02 due to an ICE which now makes the docs build fail

@asonix Not sure what happened, but i've (re)installed libzmq in the build container and rebuilt the tokio-zmq docs: https://docs.rs/tokio-zmq/0.7.0/tokio_zmq/

@konstin I've updated the rustdoc in the build container to rustdoc 1.32.0-nightly (6b9b97bd9 2018-11-15) and rebuilt pyo3: https://docs.rs/pyo3/0.5.0/pyo3/

@QuietMisdreavus Thank you!

@QuietMisdreavus Thanks so much!

If you could also rebuild async-zmq-types and futures-zmq, I would greatly appreciate it! (futures-zmq is less important because I'll be releasing a (rather large) update to that pretty soon)

Thank you!

Why does docs.rs fail to build the docs for diesel-geography while travis can build it?
It fails to build the postgis dependency, BUT docs.rs successfully builds the docs of the postgis crate itself.

I am not sure why I get this error: character literal may only contain one codepoint: 'color'

see:
https://docs.rs/crate/crossterm/0.5.0/builds/128701

@TimonPost these two lines https://github.com/TimonPost/crossterm/blob/f068ae69b1cbd4ccee43b9b9a140844368f7b667/src/modules/style/color.rs#L28

are inside the backticks, and so Rust is trying to interpret them as code.

Here's a PR: https://github.com/TimonPost/crossterm/pull/53

Can someone please rebuild rsevents-extra (build failure from September, I came to this thread but didn't comment because I saw other people complaining about similar problems with their repos and didn't want to add to the noise not realizing it wouldn't be rebuilt if I didn't comment)? If the issue with path resolution persists, I can push out a new release from the latest (neosmart/rsevents-extra@c582a9e9fb910fdbd3755e0405440c61dd414d95) which switched it over to rust 2018 which bypasses the issue entirely.

Much appreciated.

@mqudsi Done! https://docs.rs/rsevents-extra/0.1.0/rsevents_extra/

@Boscop Those docs of postgis were built with an old version of rustdoc, back in March. Attempting to build it with the nightly that docs.rs was using yields the same error. Updating rustc fixes the problem, so i've been able to build diesel-geography: https://docs.rs/diesel-geography/0.2.0/diesel_geography/

Note: Docs.rs is now running rustc 1.32.0-nightly (3e90a12a8 2018-11-29) to build/document crates.

It looks like crates using recently stabilizing features like package renaming in Cargo.toml can't build using the 2018-11-29 nightly:

thread 'main' panicked at 'ErrorMessage { msg: "feature `rename-dependency` is required\n\nconsider adding `cargo-features = [\"rename-dependency\"]` to the manifest" }

failed to parse manifest at `/home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/sval-0.0.2/Cargo.toml`', src/bin/cratesfyi.rs:142:13

I'm hitting this issue with a crate called sval.

@QuietMisdreavus Any chance you can rebuild rkv 0.5.1?

@mykmelez Done! https://docs.rs/rkv/0.5.1/rkv/

@KodrAus Looks like with the recent Cargo update in https://github.com/rust-lang/docs.rs/pull/271, we can build crates like that now: https://docs.rs/sval/0.0.4/sval/

Nightly is about a week out of date it seems.

portaudio 0.7.0 isn't building. Maybe a missing system dependency?

@Lokathor Nightly is updated manually, so unless it's causing problems and i or Onur need to update it ourselves, it will stay the same.

@bb010g It looks like the build script of portaudio uses wget to download the source tarball, which is not installed in the build container. (Ironically, if they hadn't overridden their unix_platform and used curl instead, it would have worked.) I've installed wget into the build container and the docs built just fine: https://docs.rs/portaudio/0.7.0/portaudio/

The problem is that my crate doesn't build because I need the Dec 30th or later nightly (the one where NonZeroUsize::get became const).

I just noticed that my build for tokio-zmq failed again the last time I updated it due to zmq-sys failing to build. zmq-sys built successfully for it's own documentation, though.

futures-preview alpha 11 has failed to build because the build is using an old rustc nightly from before pin was stabilised.

$ rustc --version
rustc 1.33.0-nightly (adbfec229 2018-12-17)

Do you mind updating to a newer rust nightly and rebuilding? Anything from Dec 27 onwards should be fine.

If you're going to update nightly manually please use Dec31 onwards.

Docs.rs has been updated to version 1.33.0-nightly (c2d381d39 2019-01-10).

@josephg I just tried rebuilding that crate and got even more errors. Is 0.3.0-alpha.11 incompatible with that nightly version?

@Lokathor Do you have a specific crate or list of crates you would like to be rebuilt? I can rebuild things, but i need to know what crates and versions i should do.

@asonix Some of the packages in the build container may have been lost in the recent server migration. I've installed libzmq3-dev into the build container and the documentation worked: https://docs.rs/tokio-zmq/0.9.0/tokio_zmq/

@QuietMisdreavus Thank you!

Oh! Could you also rebuild futures-zmq? It seems to have suffered the same problem

@quietmisdreavus no worries, I'll issue new versions. There's always bug fixes and features worth adding a +0.0.1 for

Is the nightly version used by docs.rs published anywhere? I used to copy it from https://github.com/rust-lang/docs.rs/blob/1a20968096e6e92fbb45223adbd2fe143ac9e957/Vagrantfile#L50 and have it in my CI, but now it seems to be "indeterminate nightly from the last manual update"? If the version was predictable, i.e. published somewhere or just "the latest nightly", then one could gate publishing on docs building for that version.

Build failure that works on 1.32 stable but failed on docs.rs' nightly: https://docs.rs/crate/palaver/0.2.1

Hi there, we've been using a stored XSS on docs.rs to render math in our docs (curve25519-dalek), and it broke because the cache is now missing. The docs.rs page redirected to this issue; is there a better way to do math rendering on docs.rs or should we try to redo the XSS?

https://docs.rs/crate/exonum/0.10.3/exonum

error: failed to run custom build command for `exonum v0.10.3`
process didn't exit successfully: `/home/cratesfyi/cratesfyi/debug/build/exonum-ef749a1527bfe7a6/build-script-build` (exit code: 101)
--- stdout
cargo:protos=/home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/exonum-0.10.3/src/proto/schema/exonum

--- stderr
thread 'main' panicked at 'protoc: Custom { kind: NotFound, error: StringError("failed to spawn `\"protoc\" \"--version\"`: No such file or directory (os error 2)") }', src/libcore/result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

I've tried to add in Cargo.toml file this:

[package.metadata.docs.rs]
dependencies = [ "protobuf-compiler" ]

But there isn't any effects.

https://docs.rs/crate/avocado/0.3.0

rustc 1.33.0-nightly (c2d381d39 2019-01-10) appears to have choked on my crate; from what I can tell based on a quick Google search, this was a compiler bug that has since been fixed, around a week ago. Updating the toolchain docs.rs uses might fix the issue.

Relevant part of the build log:

     Running `rustdoc --edition=2018 --crate-name avocado /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/avocado-0.3.0/src/lib.rs --cap-lints allow --color never -o /home/cratesfyi/cratesfyi/doc --cfg 'feature="default"' --cfg 'feature="magnet_schema"' --cfg 'feature="raw_uuid"' --cfg 'feature="schema_validation"' --cfg 'feature="uuid"' -Z unstable-options --resource-suffix -20190110-1.33.0-nightly-c2d381d39 --static-root-path / --disable-per-crate-search --extern-html-root-url 'bson=https://docs.rs/bson/0.13.0' --extern-html-root-url 'scopeguard=https://docs.rs/scopeguard/1.0.0' --extern-html-root-url 'lazy_static=https://docs.rs/lazy_static/1.2.0' --extern-html-root-url 'bitflags=https://docs.rs/bitflags/1.0.4' --extern-html-root-url 'serde_json=https://docs.rs/serde_json/1.0.37' --extern-html-root-url 'avocado_derive=https://docs.rs/avocado_derive/0.3.0' --extern-html-root-url 'serde=https://docs.rs/serde/1.0.85' --extern-html-root-url 'backtrace=https://docs.rs/backtrace/0.3.13' --extern-html-root-url 'mongodb=https://docs.rs/mongodb/0.3.12' --extern-html-root-url 'magnet_derive=https://docs.rs/magnet_derive/0.8.0' --extern-html-root-url 'compiletest_rs=https://docs.rs/compiletest_rs/0.3.18' --extern-html-root-url 'uuid=https://docs.rs/uuid/0.7.1' --extern-html-root-url 'magnet_schema=https://docs.rs/magnet_schema/0.8.0' --extern-html-root-url 'serde_derive=https://docs.rs/serde_derive/1.0.85' -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern backtrace=/home/cratesfyi/cratesfyi/debug/deps/libbacktrace-4e9ade216e19b61e.rmeta --extern bitflags=/home/cratesfyi/cratesfyi/debug/deps/libbitflags-8f5ba66b690b2b94.rmeta --extern bson=/home/cratesfyi/cratesfyi/debug/deps/libbson-ea79146b49d3cb5d.rmeta --extern magnet_schema=/home/cratesfyi/cratesfyi/debug/deps/libmagnet_schema-567a39b94cac91a6.rmeta --extern mongodb=/home/cratesfyi/cratesfyi/debug/deps/libmongodb-0a10cb39dd103020.rmeta --extern serde=/home/cratesfyi/cratesfyi/debug/deps/libserde-b94b58ed63e2f284.rmeta --extern serde_derive=/home/cratesfyi/cratesfyi/debug/deps/libserde_derive-8e4b1fd6aea00530.so --extern serde_json=/home/cratesfyi/cratesfyi/debug/deps/libserde_json-3afb344f7a2ab530.rmeta --extern uuid=/home/cratesfyi/cratesfyi/debug/deps/libuuid-a2cd05242ef2d8da.rmeta`
error[E0658]: imports can only refer to extern crate names passed with `--extern` on stable channel (see issue #53130)
   --> /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/avocado-0.3.0/src/error.rs:130:13
    |
93  | / pub enum ErrorKind {
94  | |     /// There was an error converting between JSON and a strongly-typed value.
95  | |     JsonTranscoding,
96  | |     /// There was an error converting a strongly-typed value to BSON.
...   |
124 | |     BsonSchema,
125 | | }
    | |_- not an extern crate passed with `--extern`
...
130 |           use ErrorKind::*;
    |               ^^^^^^^^^
    |
    = help: add #![feature(uniform_paths)] to the crate attributes to enable
note: this import refers to the enum defined here
   --> /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/avocado-0.3.0/src/error.rs:93:1
    |
93  | / pub enum ErrorKind {
94  | |     /// There was an error converting between JSON and a strongly-typed value.
95  | |     JsonTranscoding,
96  | |     /// There was an error converting a strongly-typed value to BSON.
...   |
124 | |     BsonSchema,
125 | | }
    | |_^

error: Compilation failed, aborting rustdoc

I have problem with using feature gates. https://docs.rs/crate/javascript_lexer/0.1.3/builds/139171 It seems that they are not recognized (used). I have the exact same version of compiler and everything works fine. Also the package contains lib.rs file which explicitly allows const_let feature

https://docs.rs/crate/salsa/0.10.0-alpha5/builds/139182 seems to have choked on version resolution or something? The build said all of the dependencies were Fresh but errored with

error[E0460]: found possibly newer version of crate `proc_macro2` which `syn` depends on
 --> /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/salsa-macros-0.10.0-alpha5/src/database_storage.rs:3:5
  |
3 | use syn::parse::{Parse, ParseStream};
  |     ^^^
  |
  = note: perhaps that crate needs to be recompiled?
  = note: the following crate versions were found:
          crate `proc_macro2`: (17 .rlibs, 13 .rmetas)
          crate `syn`: (rlib)

@hdevalence you should be able to update the html-in-header to point to the current crate instead of an old one and that should work.

@CAD97 I am getting the same error in my crate as well. @QuietMisdreavus is there some kind of cache that needs to be wiped? All those libproc_macro2-*.rlib must be from previous builds.

     Running `rustc --edition=2018 --crate-name linkme_impl /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/linkme-impl-0.1.0/src/lib.rs --color never --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C debuginfo=2 -C metadata=d7fcc9adc08ca70f -C extra-filename=-d7fcc9adc08ca70f --out-dir /home/cratesfyi/cratesfyi/debug/deps -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern proc_macro2=/home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-cacba58e679e5d8e.rlib --extern quote=/home/cratesfyi/cratesfyi/debug/deps/libquote-0841a9d20c2573fa.rlib --extern syn=/home/cratesfyi/cratesfyi/debug/deps/libsyn-1ca7323f3e8bb2ab.rlib --cap-lints allow`
error[E0460]: found possibly newer version of crate `proc_macro2` which `syn` depends on
 --> /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/linkme-impl-0.1.0/src/args.rs:1:5
  |
1 | use syn::parse::{Parse, ParseStream, Result};
  |     ^^^
  |
  = note: perhaps that crate needs to be recompiled?
  = note: the following crate versions were found:
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-cacba58e679e5d8e.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-20f6d72803feb5bb.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-6f069c3d6ee22fbf.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-7906a8793c28b4ed.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-d353b651b00a7412.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-320d2dea7875e2e6.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-e37c9336a5f8cd63.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-ae87c558fbe92a32.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-4fb2e28c08ce4bda.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-6909416e222a959d.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-cfdf1558d0d78358.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-8668129cf4b99c5a.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-c19debe127905552.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-2bdf36542b8eb440.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-ee0ea2ddb0e2da3c.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-8c593bc71ce6a0bf.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-761c5f61afb5bf29.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-d63968d4f59468b6.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-31c7967343f608d3.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-3e5d2e259e9ab07e.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-606a29195cdb0876.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-405d46703f91fda5.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-0bb771eb65ced453.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-b8e7655f2646c50f.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-ddeeddf22953a12f.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-5171d3ef1b691059.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-01f09c8af5c24476.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-d0f0adf48c483d55.rmeta
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-34e3254011803865.rlib
          crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-cf9472c254ef7f83.rmeta
          crate `syn`: /home/cratesfyi/cratesfyi/debug/deps/libsyn-1ca7323f3e8bb2ab.rlib

Checking smithay-client-toolkit v0.4.4 Fresh piston v0.40.0 Running `rustc --crate-name smithay_client_toolkit /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.4/src/lib.rs --color never --crate-type lib --emit=dep-info,metadata -C debuginfo=2 -C metadata=9e7036a9afc5b0d2 -C extra-filename=-9e7036a9afc5b0d2 --out-dir /home/cratesfyi/cratesfyi/debug/deps -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern andrew=/home/cratesfyi/cratesfyi/debug/deps/libandrew-b2c6d5bbaa18ea19.rmeta --extern bitflags=/home/cratesfyi/cratesfyi/debug/deps/libbitflags-8f5ba66b690b2b94.rmeta --extern dlib=/home/cratesfyi/cratesfyi/debug/deps/libdlib-9421ae07a81b1375.rmeta --extern lazy_static=/home/cratesfyi/cratesfyi/debug/deps/liblazy_static-78a6d1a4a27fe797.rmeta --extern memmap=/home/cratesfyi/cratesfyi/debug/deps/libmemmap-10abf772a77bc73f.rmeta --extern nix=/home/cratesfyi/cratesfyi/debug/deps/libnix-4232aded7635c9e4.rmeta --extern rand=/home/cratesfyi/cratesfyi/debug/deps/librand-b4989751547c311b.rmeta --extern wayland_client=/home/cratesfyi/cratesfyi/debug/deps/libwayland_client-4d72be63074fabb0.rmeta --extern wayland_commons=/home/cratesfyi/cratesfyi/debug/deps/libwayland_commons-1a2be259bde327a5.rmeta --extern wayland_protocols=/home/cratesfyi/cratesfyi/debug/deps/libwayland_protocols-d55313116688376e.rmeta --cap-lints allow -L native=/home/cratesfyi/cratesfyi/debug/build/libloading-98d4d2169b66ecfc/out` error[E0460]: found possibly newer version of crate `proc_macro2` which `syn` depends on --> /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/num-derive-0.2.4/src/lib.rs:47:1 | 47 | extern crate syn; | ^^^^^^^^^^^^^^^^^ | = note: perhaps that crate needs to be recompiled? = note: the following crate versions were found: crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-cacba58e679e5d8e.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-20f6d72803feb5bb.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-6f069c3d6ee22fbf.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-7906a8793c28b4ed.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-d353b651b00a7412.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-320d2dea7875e2e6.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-e37c9336a5f8cd63.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-ae87c558fbe92a32.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-4fb2e28c08ce4bda.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-6909416e222a959d.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-cfdf1558d0d78358.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-8668129cf4b99c5a.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-c19debe127905552.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-2bdf36542b8eb440.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-ee0ea2ddb0e2da3c.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-8c593bc71ce6a0bf.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-761c5f61afb5bf29.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-d63968d4f59468b6.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-31c7967343f608d3.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-3e5d2e259e9ab07e.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-606a29195cdb0876.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-405d46703f91fda5.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-0bb771eb65ced453.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-b8e7655f2646c50f.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-ddeeddf22953a12f.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-5171d3ef1b691059.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-01f09c8af5c24476.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-d0f0adf48c483d55.rmeta crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-34e3254011803865.rlib crate `proc_macro2`: /home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-cf9472c254ef7f83.rmeta crate `syn`: /home/cratesfyi/cratesfyi/debug/deps/libsyn-8b0d82d9606626c2.rlib

I'm getting a build failure due to my use of relative paths in lib.rs on a 2018 crate. I'm confused though, because the same code is passing on Travis.

https://docs.rs/crate/syn-select/0.1.1/builds/139804

Failed build thanks to feature gates. Content of the package clearly shows that the missing features are enabled for the library

I've updated docs.rs to rustc 1.34.0-nightly (d8a0dd7ae 2019-01-28) and a more recent Cargo library, and rebuilt a bunch of crates which failed on the last version. Please double-check your crates and let me know if they're still broken.

@QuietMisdreavus awesome work, fixed mine library at least. Have you only updated build environment or have you done also some other changes?

@QuietMisdreavus https://docs.rs/exonum/0.10.3/exonum/ still broken. Could you please add dependencies: libprotobuf-dev and protobuf-compiler ?

@retep007 I had to update the Cargo library that docs.rs was using, and made some changes to handle the new static files that rustdoc had added since the nightly that it was using. Otherwise, i didn't make any functional changes to the docs.rs site code.

@aleksuss Done! https://docs.rs/exonum/0.10.3/exonum/

@aleksuss All done!

I'm seeing document build failure on diff-enum crate as follows:

https://docs.rs/crate/diff-enum/0.1.2/builds/140415

$ cratesfyi ...
    Updating crates.io index
 Downloading crates ...
  Downloaded diff-enum v0.1.2
       Fresh unicode-xid v0.1.0
       Fresh proc-macro2 v0.4.27
       Fresh quote v0.6.11
    Checking syn v0.15.26
     Running `rustc --crate-name syn /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/syn-0.15.26/src/lib.rs --color never --crate-type lib --emit=dep-info,metadata -C debuginfo=2 --cfg 'feature="clone-impls"' --cfg 'feature="default"' --cfg 'feature="derive"' --cfg 'feature="parsing"' --cfg 'feature="printing"' --cfg 'feature="proc-macro"' --cfg 'feature="proc-macro2"' --cfg 'feature="quote"' -C metadata=f59778eafafa809e -C extra-filename=-f59778eafafa809e --out-dir /home/cratesfyi/cratesfyi/debug/deps -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern proc_macro2=/home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-2bac3549b49d7aab.rmeta --extern quote=/home/cratesfyi/cratesfyi/debug/deps/libquote-6d25fe71b9101586.rmeta --extern unicode_xid=/home/cratesfyi/cratesfyi/debug/deps/libunicode_xid-cc9fa4c041ed5570.rmeta --cap-lints allow`
 Documenting diff-enum v0.1.2
     Running `rustdoc --edition=2018 --crate-name diff_enum /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/diff-enum-0.1.2/src/lib.rs --cap-lints allow --color never -o /home/cratesfyi/cratesfyi/doc -Z unstable-options --resource-suffix -20190128-1.34.0-nightly-d8a0dd7ae --static-root-path / --disable-per-crate-search --extern-html-root-url 'proc_macro2=https://docs.rs/proc-macro2/0.4.27' --extern-html-root-url 'cargo_husky=https://docs.rs/cargo-husky/1.3.0' --extern-html-root-url 'quote=https://docs.rs/quote/0.6.11' --extern-html-root-url 'syn=https://docs.rs/syn/0.15.26' -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern proc_macro2=/home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-2bac3549b49d7aab.rmeta --extern quote=/home/cratesfyi/cratesfyi/debug/deps/libquote-6d25fe71b9101586.rmeta --extern syn=/home/cratesfyi/cratesfyi/debug/deps/libsyn-f59778eafafa809e.rmeta`
error: internal compiler error: src/librustc/hir/def.rs:257: attempted .def_id() on invalid def: NonMacroAttr(Builtin)

thread 'rustc' panicked at 'Box', src/librustc_errors/lib.rs:605:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

error: Unrecognized option: 'resource-suffix'

thread 'main' panicked at 'ProcessError { desc: "process didn\'t exit successfully: `rustdoc --edition=2018 --crate-name diff_enum /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/diff-enum-0.1.2/src/lib.rs --cap-lints allow --color never -o /home/cratesfyi/cratesfyi/doc -Z unstable-options --resource-suffix -20190128-1.34.0-nightly-d8a0dd7ae --static-root-path / --disable-per-crate-search --extern-html-root-url \'proc_macro2=https://docs.rs/proc-macro2/0.4.27\' --extern-html-root-url \'cargo_husky=https://docs.rs/cargo-husky/1.3.0\' --extern-html-root-url \'quote=https://docs.rs/quote/0.6.11\' --extern-html-root-url \'syn=https://docs.rs/syn/0.15.26\' -L dependency=/home/cratesfyi/cratesfyi/debug/deps --extern proc_macro2=/home/cratesfyi/cratesfyi/debug/deps/libproc_macro2-2bac3549b49d7aab.rmeta --extern quote=/home/cratesfyi/cratesfyi/debug/deps/libquote-6d25fe71b9101586.rmeta --extern syn=/home/cratesfyi/cratesfyi/debug/deps/libsyn-f59778eafafa809e.rmeta` (exit code: 1)", exit: Some(ExitStatus(ExitStatus(256))), output: None }

Could not document `diff-enum`.', src/bin/cratesfyi.rs:142:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.

It looks related to attribute style proc macro:

error: internal compiler error: src/librustc/hir/def.rs:257: attempted .def_id() on invalid def: NonMacroAttr(Builtin)

@rhysd That one looks like a bug in rustdoc! I've reported it upstream; i'll try to take a look today.

@QuietMisdreavus Thank you so much! I'll track the issue.

@QuietMisdreavus could you check the isilon library? It builds fine on travis but it's not available on docs.rs for some reason. I'm about to publish a new version soon

@cholcombe973 There looks to be a problem with how long the readme is. Docs.rs saves the content of the repo's README.md in its database, but that column can only fit 50KiB of text. Because the readme of that repo contains the complete listing of the API it's binding, the file is 153KB big, which causes a database error when adding the documentation:

2019/02/14 20:52:45 [ERROR] cratesfyi::docbuilder::queue: Failed to build package isilon-5.0.0 from queue: database error: ERROR: value too long for type character varying(51200)

Is there a way to change the codegen you're using to not have this listing in the readme?

Yup I'll truncate the Readme. Thanks for looking into this!

Our crate Rustler needs Erlang installed on the build machine to work. It used to be installed, but I think it has been removed recently?

If the build machine is debian based, I think having erlang and erlang-dev should do the trick.

Thanks!

I'm hitting a docs build issue with my cccolutils crate - it depends on the shared library from krb5 and the <krb5.h> header for the build. The packages libkrb5-dev (debian/ubuntu) or krb5-devel (fedora, etc.) should provide what's missing on your build system.

EDIT: Even after adding this:

[package.metadata.docs.rs]
dependencies = [
    "libkrb5-dev"
]

to my crate's Cargo.toml file, the build continues to fail with the same error (No such file or directory: krb5.h), although that package would contain the necessary file.

@hansihe Looks like only erlang-dev was needed. I've rebuilt Rustler: https://docs.rs/rustler/0.20.0/rustler/

@decathorpe That metadata field is currently not used by docs.rs, though we are planning to use it in the future. For now, i've installed libkrb5-dev into the build container and rebuilt cccolutils: https://docs.rs/cccolutils/0.1.0/cccolutils/

@QuietMisdreavus Great, thanks! I see the documentation finally built successfully :smile:

I also submitted a PR to add a small clarifying comment to the example configuration on the docs.rs about page, mentioning that the dependencies key isn't being used yet: https://github.com/rust-lang/docs.rs/pull/318 - it might prevent this confusion in the future :)

Documentation build failed for https://docs.rs/crate/fprint-sys (and https://docs.rs/crate/fprint-sys too). These packages depends on fprint.h from system package libfprint-dev.


Details

Running `/home/cratesfyi/cratesfyi/debug/build/fprint-sys-9b82db5ad76ba8d1/build-script-build`
thread 'main' panicked at 'ErrorMessage {
    msg: "failed to run custom build command for `fprint-sys v0.1.1`\nprocess didn\'t exit successfully: `/home/cratesfyi/cratesfyi/debug/build/fprint-sys-9b82db5ad76ba8d1/build-script-build` (exit code: 101)\n--- stderr\nthread \'main\' panicked at \'called `Result::unwrap()` on an `Err` value: Failure { command: \"\\\"pkg-config\\\" \\\"--libs\\\" \\\"--cflags\\\" \\\"libfprint\\\"\", output: Output { status: ExitStatus(ExitStatus(256)), stdout: \"\", stderr: \"Package libfprint was not found in the pkg-config search path.\\nPerhaps you should add the directory containing `libfprint.pc\\\'\\nto the PKG_CONFIG_PATH environment variable\\nNo package \\\'libfprint\\\' found\\n\" } }\', src/libcore/result.rs:997:5\nnote: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.\n"
}', src/bin/cratesfyi.rs:142:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.
stderr: "Package libfprint was not found in the pkg-config search path.
Perhaps you should add the directory containing 'libfprint.pc'
nto the PKG_CONFIG_PATH environment variable
No package 'libfprint' found"

@QuietMisdreavus Thanks!

vergen needs to be rebuilt using a compiler with stable 2018 edition.

https://docs.rs/crate/vergen/3.0.4/builds/121844

Hi, it seems like my crate was built on a machine without the x86_64-pc-windows-gnu target added, is this the proper incantation to use?

@jmgao We haven't built crates for the windows-gnu targets since https://github.com/rust-lang/docs.rs/pull/254, and since our server move shortly afterward we haven't even had the targets installed in the build container. Does your crate require windows-gnu, or will windows-msvc work?

@QuietMisdreavus Ah, thanks, I'll give that a try.

futures-preview should have been built with a newer nightly.

Same goes for gen-stream and tarpc.

@vorot93 Done!

https://docs.rs/futures-preview/0.3.0-alpha.14/futures/
https://docs.rs/gen-stream/0.2.2/gen_stream/
https://docs.rs/tarpc/0.16.0/tarpc/

Looks like a lot of failures happened recently because of the stabilization of alloc. I'll try to rebuild some of these.

The "paho-mqtt" crate (https://docs.rs/crate/paho-mqtt/0.5.0) is a wrapper around a C library which, by default, it builds automatically. This requires _cmake_ and _gcc_ on the build system. Is there a way to indicate this so that Docs.rs does not report a build failure?

I'd appreciate if someone would restart my build once newer nightly (with stable futures) gets onto docs.rs
https://docs.rs/crate/async-timer/

@QuietMisdreavus futures-preview strikes again. Need a newer nightly.

My crate failed to be documented because of a really weird internal compiler error. I already filed an issue in the appriorate repository and would appreciate if you can document my project on Stable where it is successful.

The qmetaobject crate seems to fail to build due to missing Qt5 libraries. Error message:

fatal error: QtCore/QObject: No such file or directory

Would it be possible to install these on the builder?

My abi_stable crate v0.4.0 is failing to document because pulldown-cmark has(had?) a parsing bug.

 'unexpected node in tree: Header(3)', /cargo/registry/src/github.com-1ecc6299db9ec823/pulldown-cmark-0.4.1/src/parse.rs:1019:29

Context:
rustc 1.36.0-nightly (d35181ad8 2019-05-20)
cratesfyi 0.6.0 (be80566 2019-05-06)

It documents just fine on stable Rust.

Edit:

I was able to get abi_stable 0.4.1 to document by replacing all ### headers with <h3> ... </h3> surrounding the entire line.

cmark-gfm-sys seems to fail during the build process, but I just tested it locally and it works (I know the argument "it works on my machine" is not valid, but the generation process should be able to run on any platform). Here it indicates that it does not find a file that exists yet.

@HelloEdit I got a failure when building locally, so it may be broader than docs.rs's build container. It looks like the error is when it's trying to load the cmark-gfm-extension_api.h header from the cmark-gfm-core-extensions.h header, so there may be an issue of properly passing the include directories to bindgen? I'm curious to see how it works for you.

@QuietMisdreavus Hi, you're right, I was in a "polluted" environment (the library was already installed and shared by the system). I tried to make the compiler find the library that the build.rs file builds but couldn't find a solution :c

315

The problem has been located and resolved. Thank you. Thank you!

Hi, thanks for your great work!

The doc for emd 0.1.0 is failing to build: https://docs.rs/crate/emd/0.1.0/builds/168511. (The crate itself builds and runs correctly https://travis-ci.org/gchers/rust-emd.)

Further notes

Note that emd has a fairly weird build procedure. It's a wrapper of a C library hosted on github. Therefore, it fetches the library (as a zip file of the desired library version) and compiles it. From the logs of doc.rs, it looks like the file is not downloaded at all.

Also, note that in principle there's no need to follow all the building procedure in order to see the documentation.

@gchers Hi, why not use git submodules instead of downloading the source code? The source code would be cloned from github at the same time as your code.

You're right, that makes totally sense. And I expect that would also fix the issue with doc.rs, right?

Thanks:)

Yes, cargo package also takes into account the sub module ^^

Hi, Thanks for running this great service :)

Leptonica-sys and Tesseract-sys both fail to generate documentation.

I suspect installing libtesseract-dev (and its dependency libleptonica-dev) would fix the documentation for both crates.

Thanks for building this site!

gpgme version 0.9.0 fails to build, but the earlier versions works fine.

If you would be so kind to install nettle-dev in your build environment, that would allow nettle-sys, nettle, sequoia-openpgp, and all crates depending on it to build.

I've got a project (https://docs.rs/crate/nrfxlib-sys/0.1.4/builds/171552) which relies on the user checking out a third-party git repo and specifying the path to it as an environment variable. I didn't want to bundle the source code because of a) I have questions about the license the third party library is under and b) it's under development so I'd be chasing updates all the while. Any ideas how to get docs.rs to build this, or how I could build the docs myself and upload them?

The docs for my crate ccl are failing to build with no major changes made since the last working version.

Looks like the crate for glfw is failing to build. Did you guys not install cmake?

Also blingfire is failing because cmake is missing.

https://docs.rs/crate/bitcoin-zmq/0.1.0/builds
fails to compile due to libzmq3-dev missing?

hey there,
my crate: https://docs.rs/crate/ruspiro-boot/0.1.1 failed to build as I've set the default target to be "armv7-unknown-linux-gnueabihf", and the log fail complains about not installed compiler?:
stderr: "\n\nerror occurred: Failed to find tool. Is `arm-linux-gnueabihf-gcc` installed?

The Cargo.toml part to control doc.rs behaviour:

[package.metadata.docs.rs]
all-features = true
default-target = "armv7-unknown-linux-gnueabihf"
rustc-args = [
    "-C target-cpu=cortex-a53",
    "-C target-feature=+a53,+fp-armv8,+v8,+vfp3,+d16,+thumb2,+neon"
    ]

This build failed due to hitting https://github.com/rust-lang/rust/issues/61804:
https://docs.rs/crate/syn-next/1.0.0-rc3/builds/178036

It looks like the build was with rustc 1.38.0-nightly (95b1fe560 2019-07-20). Would it be possible to update the nightly to pull in the fix for that bug? It was fixed in https://github.com/rust-lang/rust/pull/62086 in nightlies newer than 2019-07-28.

rustc 1.38.0-nightly (95b1fe560 2019-07-20) also fails to build futures-preview 0.3.0-alpha.18 and crates that depend on it, for issues unrelated with the above mentioned ICE, so an update of the nightly would be great!

I see the rustc version has been updated, but it looks like crates that have failed before were not rebuilt after the update. (https://docs.rs/crate/futures-io-preview/0.3.0-alpha.18)

error[E0514]: found crate `bitvec` compiled by an incompatible version of rustc
  --> /home/cratesfyi/.cargo/registry/src/github.com-1ecc6299db9ec823/mbrman-0.1.0/src/lib.rs:72:5
   |
72 | use bitvec::prelude::*;
   |     ^^^^^^
   |
   = help: please recompile that crate using this compiler (rustc 1.39.0-nightly (bea0372a1 2019-08-20))
   = note: the following crate versions were found:
           crate `bitvec` compiled by rustc 1.36.0 (a53f9df32 2019-07-03): /home/cratesfyi/cratesfyi/debug/deps/libbitvec-037542c063cb88fa.rmeta

error: aborting due to previous error

(logs)

I got this error but I cannot reproduce locally using rustc 1.39.0-nightly (4295eea90 2019-08-30)

https://docs.rs/crate/tentacle/0.2.4
https://docs.rs/crate/tentacle-secio/0.1.10
https://docs.rs/crate/tentacle-ping/0.3.6
https://docs.rs/crate/tentacle-identify/0.2.7
https://docs.rs/crate/tentacle-discovery/0.2.6

These libraries have encountered a problem. They all have 2 features to choose from, but they can't choose all or not noe. The default selection is empty. I don't know how this is expressed in toml metadata, so the doc generation for these libraries has failed.

#[cfg(all(feature = "flatc", feature = "molc"))]
compile_error!("features `flatc` and `molc` are mutually exclusive");
#[cfg(all(not(feature = "flatc"), not(feature = "molc")))]
compile_error!("Please choose a serialization format via feature. Possible choices: flatc, molc");

I know how to config it now. https://docs.rs/about

Hi, thank you for running Docs.rs!

https://docs.rs/crate/clay-core/0.1.0

The build failed due to error: could not find `format_args` in `core` while building ocl. The cause might be similar to https://github.com/rust-lang/rust/issues/63687.

Maybe the problem is in rustc 1.39.0-nightly (618768492 2019-09-05) used by Docs.rs. I cannot reproduce this error locally using rustc 1.39.0-nightly (f0b58fcf0 2019-09-11).

@nthend updated the nightly on docs.rs and manually queued a build for your crate!

Hi! It'd be nice to have docs for my Qt crates (qt_core, qt_gui, qt_widgets, qt_ui_tools, qt_3d_core, qt_3d_render, qt_3d_input, qt_3d_logic, qt_3d_extras, qt_charts, qt_qml) on docs.rs. Can you install the corresponding Qt development packages in your build environment? Qt >= 5.9.7 will do.

Ideally, the RITUAL_RUSTDOC=1 environment variable should also be set. This will enable documentation of all available items, independent on the current Qt version. This is basically a hack to achieve the behavior of #[cfg(rustdoc)] that is not available on stable, unfortunately. Or, if you don't want to pass ritual-specific variables, you may set an env var like IS_DOCS_RS=1, and I'll read it in my build script.

Build log

As this docs building.

It's obvious that docs.rs does not execute proc-macro-attribute, because each async fn in trait will be transferred into a normal fn by proc-macro-attribute.

Cloning this repo and executing cargo doc --open --all-features locally works well.

abi_stable and abi_stable_derive are not in the queue/Recent failures/recent releases lists,even though updates of other crates released afterwards were built.

Update
While the 0.7.0 version wan't built,the 0.7.1 built just fine.

I created a new crate big_enum_set. But the docs are not showing up on docs.rs. cargo doc works locally.

Perhaps related?

We have the same issue with mockiato. No build has been started for version 0.9.4.

Fresh build of proc-macro2 has failed too. From the log, it looks like some misconfiguration in the docker create command - the argument RUSTFLAGS=--cfgprocmacro2_semver_exempt seems to be incorrect. It comes from the following section of Cargo.toml:

[package.metadata.docs.rs]
rustdoc-args = ["--cfg", "procmacro2_semver_exempt"]

I wasn't able to find another example yet, but possibly this will crash docs building for any crate with similar configuration.

@Cerberuser yep, that's indeed a bug in docs.rs. Opened a PR with a fix: https://github.com/rust-lang/docs.rs/pull/427. Once the PR is merged we will rebuild that crate.

pgp is failing: https://docs.rs/crate/pgp/0.2.2/builds/187802, but cargo doc runs fine locally

How do I know actually if it's a doc-rs problem or not? A single issue on GitHub seems pretty inconvenient for seeking some help...

@dignifiedquire rebuilt pgp 0.2.2! It was a docs.rs error, but it was fixed a few days ago.

@Cerberuser rebuilt proc-macro2 as well after the fix for the issue landed, but there was a compilation error: https://docs.rs/crate/proc-macro2/1.0.5/builds/190515.

@pietroalbini Could you trigger a build for mockiato = "0.9.4" as well?

@pietroalbini Couldn't reproduce the failure myself, so pinging the author - cc @alexcrichton

@jeremystucki queued both the failed mockiato versions (0.9.3 and 0.9.4) again!

Hi everyone!

It became apparent to us that this issue doesn't really scale: people posting here start receiving useless notifications and need to manually unsubscribe from the thread, and it's hard for us to keep track of which crates are fixed and which need action from our end.

We now recommend everyone to create a separate issue for each crate, and to aid that we added issue templates for broken crates and sandbox limit increase requests, changing the website to point to them. This issue will be also locked to prevent further reports here.

If your crate still fails please open a new issue and we'll look into it!

Was this page helpful?
0 / 5 - 0 ratings