Repository navigation
std::os::windows missing on http://doc.rust-lang.org/nightly/std/os/ #24658
Description
The builders are running rustdoc on Linux, so #[cfg(windows)] is false.
Maybe the platform rustdoc in running on should not be relevant for generating documentation. Could rustdoc be run with both --cfg unix and --cfg windows?
Reacted by Ruud van Asseldonk, Brian Green, Alex Chan, Jordan Miner, Stanislav Tkach, Benjamin Saunders and Maxim Ryazanov
Reacted by Eyal Kalderon
Activity
steveklabnik commentedon Apr 21, 2015
I would imagine this wouldn't work, as they have implementaitons that conflict and such.
nwin commentedon Apr 21, 2015
This is actually not so trivial. What about things that exist on both Platforms but are different?
klutzy commentedon Apr 21, 2015
cc #1998
SimonSapin commentedon Apr 21, 2015
My suggested solution probably doesn’t work, but the issue remains that non-Linux things should still be documented.
SimonSapin commentedon Apr 21, 2015
Yes, this sounds like a special case of #1998.
steveklabnik commentedon Apr 21, 2015
I'm going to nominate this particular version, as it would be really unfortunate for the official docs to only have linux docs. Maybe we can have something bespoke for 1.0 at first until the underlying bug is fixed
nwin commentedon Apr 21, 2015
The most straightforward solution is probably to compile all docs separately and add a little pop-up box on the top to switch between Windows <-> Linux <-> Mac. I suppose one needs some more metadata to avoid that google gets confused…
lambda commentedon Apr 21, 2015
rust-lang/rfcs#915 is a postponed RFC that proposes one possible solution.
lambda commentedon Apr 21, 2015
I think that that case should generally be avoided, shouldn't it? It would be confusing to have the same functionality available on multiple platforms, but with conflicting implementations; instead, if functionality differs meaningfully, they should probably have different names. For example, in the standard library, there are
std::os::unixandstd::os::windows, so even if you happened to have some operation with the same name, they'd be in different modules and so could be documented separately.Are there current cases in the standard library or widely used crates in which items with the same name but conflicting signatures exist on the different platforms?
nwin commentedon Apr 21, 2015
I was thinking of
libc::types::os::common::bsd44::sockaddr_in. That struct is defined differently on Darwin and Linux (probably also Windows). I’m pretty sure there are more surprises like this lurking around.SimonSapin commentedon Apr 21, 2015
It would be unfortunate to duplicate the entire set of documentation for a comparatively small set of differences.
lambda commentedon Apr 21, 2015
Ah, you're right. There are a bunch of those cases in
libc. I guess that means that thecfg(doc)approach probably won't work.Agreed, especially since you couldn't have just those three choices, you would need to be able to switch based on any
cfgoption that could affect the set of methods available.Given that it looks like it will need to support displaying different signatures for different platforms, it seems like the best you could do is list each of them, with the appropriate
cfgflags listed to disambiguate which one is for which platform. That might get a little cumbersome forlibc, but shouldn't affect most other code since most code should be common that doesn't depend on the platform, or platform-specific and organized in a platform-specific module; cases likelibcshould be more often the exception rather than the rule.19 remaining items
Rollup merge of rust-lang#73566 - jyn514:name-resolve-first, r=eddyb
Rollup merge of rust-lang#73566 - jyn514:name-resolve-first, r=eddyb
Rollup merge of rust-lang#73566 - jyn514:name-resolve-first, r=eddyb
Rollup merge of rust-lang#73566 - jyn514:name-resolve-first, r=eddyb