-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc: reexported type aliases are not preserved in function signatures #15823
Comments
Also, the lifetime |
Related to #15099 |
This must be fixed because it makes writing portable programs impossible. |
@mahkoh, how does a rustdoc rendering bug affect the portability of a program? |
@huonw: Type aliases are often used to hide platform specific types. If the documentation shows that a function takes a i64, but it actually takes a c_long, then it won't compile on platforms where c_long is not i64. |
I just run into this issue. In my case, the types being show by the doc are not even public. You can see the problem on this doc output. I don't know if it helps, but the types are being aliased here in my code. |
This file:
still mis-renders: though as @icorderi mentions, the titles are correct. |
Triage: no changes since my last comment |
Seems to be working now so closing. |
I don't think this issue is fully fixed (correct me if I'm wrong); for example, for Type alias is used in the sub-crate code: https://github.com/heim-rs/heim/blob/095768ff6a580b27727b6958521392bb5f86a443/heim-cpu/src/freq.rs#L20-L22 And whole this crate is re-exported with Docs for sub-crate are rendered almost correctly: https://docs.rs/heim-cpu/0.0.10/heim_cpu/struct.CpuFrequency.html#method.current |
Here is a minimally working example for this issue: https://github.com/svartalf/rust-issue-15823 |
It works fine for me? Version 1.43. |
@GuillaumeGomez thanks for getting back to this issue! Unfortunately, I still can reproduce it with the example from my previous comment and Same happens at docs.rs for |
This is still an issue for me on rust 1.60.0-nightly. |
It seems to be a tricky issue to fix. I opened rust-lang/compiler-team#504 so we'll see if it'll be able to fix this problem. In the meantime, to add a test for this in rustdoc: src/test/rustdoc/alias-reexport.rs// aux-build:alias-reexport.rs
// aux-build:alias-reexport2.rs
#![crate_name = "foo"]
extern crate alias_reexport2;
// @has 'foo/reexport/fn.foo.html'
// @has - '//*[@class="docblock item-decl"]' 'pub fn foo() -> Reexport'
// @has 'foo/reexport/fn.foo2.html'
// @has - '//*[@class="docblock item-decl"]' 'pub fn foo2() -> Result<Reexport, ()>'
// @has 'foo/reexport/type.Reexported.html'
// @has - '//*[@class="docblock item-decl"]' 'pub type Reexported'
#[doc(inline)]
pub use alias_reexport2 as reexport; src/test/rustdoc/alias-reexport2.rs// aux-build:alias-reexport.rs
#![crate_name = "foo"]
extern crate alias_reexport;
use alias_reexport::Reexported;
// @has 'foo/fn.foo.html'
// @has - '//*[@class="docblock item-decl"]' 'pub fn foo() -> Reexported'
pub fn foo() -> Reexported { 0 }
// @has 'foo/fn.foo2.html'
// @has - '//*[@class="docblock item-decl"]' 'pub fn foo2() -> Result<Reexported, ()>'
pub fn foo2() -> Result<Reexported, ()> { Ok(0) } src/test/rustdoc/auxiliary/alias-reexport.rspub type Reexported = u8; src/test/rustdoc/auxiliary/alias-reexport2.rsextern crate alias_reexport;
pub use alias_reexport::Reexported;
// @has 'foo/fn.foo.html'
// @has - '//*[@class="docblock item-decl"]' 'pub fn foo() -> Reexported'
pub fn foo() -> Reexported { 0 }
// @has 'foo/fn.foo2.html'
// @has - '//*[@class="docblock item-decl"]' 'pub fn foo2() -> Result<Reexported, ()>'
pub fn foo2() -> Result<Reexported, ()> { Ok(0) } |
The code mistakenly assumed that c_char was i8 on all Rust platforms, but that is not true on Linux, so this is causing type mismatch errors at build time on Linux. (This mistake of mine was presumably reinforced by Rust issue #15823, which is an issue with rustdoc rendering some type aliases in function signatures as the pointed-to type and not by the alias name, which--among other effects--causes CStr::from_raw() and CString::into_raw() to show `i8` in their type signatures instead of `c_char`.) See also: rust-lang/rust#15823
…ux (#45) The code mistakenly assumed that c_char was i8 on all Rust platforms, but that is not true on Linux, so this is causing type mismatch errors at build time on Linux. (This mistake of mine was presumably reinforced by Rust issue #15823, which is an issue with rustdoc rendering some type aliases in function signatures as the pointed-to type and not by the alias name, which--among other effects--causes CStr::from_raw() and CString::into_raw() to show `i8` in their type signatures instead of `c_char`.) See also: rust-lang/rust#15823
Document that CStr::as_ptr returns a type alias Rustdoc resolves type aliases too eagerly rust-lang#15823 which makes the [std re-export](https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#method.as_ptr) of `CStr::as_ptr` show `i8` instead of `c_char`. To work around this I've added info about `c_char` in the method's description. BTW, I've also added a comment to what-not-to-do example in case someone copypasted it without reading the surrounding text.
Document that CStr::as_ptr returns a type alias Rustdoc resolves type aliases too eagerly rust-lang#15823 which makes the [std re-export](https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#method.as_ptr) of `CStr::as_ptr` show `i8` instead of `c_char`. To work around this I've added info about `c_char` in the method's description. BTW, I've also added a comment to what-not-to-do example in case someone copypasted it without reading the surrounding text.
#112853 allowed to make a great step forward into fixing this issue. |
The recently added
iterate
function uses theIterate
type alias as its result type. It is correctly displayed in http://static.rust-lang.org/doc/master/core/iter/fn.iterate.html but not in http://static.rust-lang.org/doc/master/std/iter/fn.iterate.html.The text was updated successfully, but these errors were encountered: