profile
viewpoint

pull request commentrust-lang/rust

Don't print "const" keyword on non-nightly build if rustc_const_unstable is used on the item

Looks good. Just needs some tests like src/test/rustdoc/const-display.rs but for methods.

GuillaumeGomez

comment created time in a day

Pull request review commentrust-lang/rust

Doc alias checks: ensure only items appearing in search index can use it

+#![feature(doc_alias)]++pub struct Bar;+pub trait Foo {+    type X;+    fn foo() -> Self::X;+}++#[doc(alias = "foo")] //~ ERROR+extern {}++#[doc(alias = "bar")] //~ ERROR+impl Bar {+    #[doc(alias = "const")] //~ ERROR

This shouldn't be an error. It's only consts in trait impls that don't appear in the search index. This one does appear.

GuillaumeGomez

comment created time in a day

pull request commentrust-lang/rust

Fix intra-doc links for associated items

I would prefer only considering traits in scope. Considering all traits means we wouldn't ever be able to link to the correct associated item or warn about ambiguities because dependencies could always add new traits and cause links to become ambiguous.

jyn514

comment created time in a day

pull request commentrust-lang/rust

Stabilize "--display-warnings" option

Looking at this a bit closer, --test-args --nocapture will interleave the outputs from many tests unless you also pass --test-args --test-threads=1 so it isn't really the same as --display-warnings which doesn't have that issue.

--display-warnings actually enables --show-output. We could instead just allow --test-args --show-output to work (currently it's ignored because --display-warnings takes precedence) so we wouldn't need a dedicated --display-warnings.

GuillaumeGomez

comment created time in a day

pull request commentrust-lang/rust

Add support for "true"/"false" intra doc link

tried to use these in #73618 and found that they didn't work.

If that's really the only use case then this definitely isn't worth the complexity.

GuillaumeGomez

comment created time in a day

pull request commentrust-lang/rust

Stabilize "--display-warnings" option

To reiterate the concerns from https://github.com/rust-lang/rust/issues/41574#issuecomment-373758210 and https://github.com/rust-lang/rust/issues/41574#issuecomment-373804164. --display-warnings seems to do 3 fairly unrelated things:

  1. It enables all lints when building docs or collecting doctests.

    The reason most lints are disabled in rustdoc is because they simply don't work. Adding a command line option to enable them again doesn't seem useful.

  2. It displays the output of rustc when compiling doctests even if they pass.

    Passing --test-args --nocapture will already do this. I don't know why we would need another option to do the same thing.

  3. It stops the automatic adding of #![allow(unused)] to doctests.

    You can already do this be adding a crate level attribute like #![doc(test(attr(warn(warnings))))]. Although I'm tempted to say we should stop adding #![allow(unused)] in general because we don't display warnings if the doctest passes anyway and if it fails displaying these lints can be useful.

So overall, what actually are the use cases for --display-warnings?

GuillaumeGomez

comment created time in a day

pull request commentrust-lang/rust

Add support for "true"/"false" intra doc link

bool is basically an enum so having true and false link to the page for bool the same way None and Some link to the page for Option makes some sense. I don't think linking to the keyword pages is better but then again I'm not a fan of the keyword pages in general. How often are we expecting people to use this, and for what?

GuillaumeGomez

comment created time in 2 days

Pull request review commentrust-lang/rust

Fix intra-doc links for associated items

 impl<'a, 'tcx> LinkCollector<'a, 'tcx> {                         } else {                             Ok((ty_res, Some(format!("{}.{}", kind, item_name))))                         }-                    } else {-                        self.variant_field(path_str, current_item, module_id)-                    }+                    }),+                _ => None,+            };+            res.unwrap_or_else(|| {+                if ns == Namespace::ValueNS {+                    self.variant_field(path_str, current_item, module_id)+                } else {+                    Err(ErrorKind::ResolutionFailure)                 }-                _ => self.variant_field(path_str, current_item, module_id),-            }+            })         } else {             debug!("attempting to resolve item without parent module: {}", path_str);             Err(ErrorKind::ResolutionFailure)         }     } } +fn resolve_associated_trait_item(+    did: DefId,+    item_name: Symbol,+    ns: Namespace,+    cx: &DocContext<'_>,+) -> Option<ty::AssocKind> {+    let ty = cx.tcx.type_of(did);+    // First consider automatic impls: `impl From<T> for T`+    let implicit_impls = crate::clean::get_auto_trait_and_blanket_impls(cx, ty, did);+    let mut candidates: Vec<_> = implicit_impls+        .flat_map(|impl_outer| {+            match impl_outer.inner {+                ImplItem(impl_) => {+                    debug!("considering auto or blanket impl for trait {:?}", impl_.trait_);+                    // Give precedence to methods that were overridden+                    if !impl_.provided_trait_methods.contains(&*item_name.as_str()) {+                        let mut items = impl_.items.into_iter().filter_map(|assoc| {+                            if assoc.name.as_deref() != Some(&*item_name.as_str()) {+                                return None;+                            }+                            let kind = assoc+                                .inner+                                .as_assoc_kind()+                                .expect("inner items for a trait should be associated items");+                            if kind.namespace() != ns {+                                return None;+                            }++                            trace!("considering associated item {:?}", assoc.inner);+                            // We have a slight issue: normal methods come from `clean` types,+                            // but provided methods come directly from `tcx`.+                            // Fortunately, we don't need the whole method, we just need to know+                            // what kind of associated item it is.+                            Some((assoc.def_id, kind))+                        });+                        let assoc = items.next();+                        debug_assert_eq!(items.count(), 0);+                        assoc+                    } else {+                        // These are provided methods or default types:+                        // ```+                        // trait T {+                        //   type A = usize;+                        //   fn has_default() -> A { 0 }+                        // }+                        // ```+                        let trait_ = impl_.trait_.unwrap().def_id().unwrap();+                        cx.tcx+                            .associated_items(trait_)+                            .find_by_name_and_namespace(+                                cx.tcx,+                                Ident::with_dummy_span(item_name),+                                ns,+                                trait_,+                            )+                            .map(|assoc| (assoc.def_id, assoc.kind))+                    }+                }+                _ => panic!("get_impls returned something that wasn't an impl"),+            }+        })+        .collect();++    // Next consider explicit impls: `impl MyTrait for MyType`+    // Give precedence to inherent impls.+    if candidates.is_empty() {+        // FIXME: As an optimization, this could only search traits in scope.+        let traits = traits_implemented_by(cx.tcx, did);+        debug!("considering traits {:?}", traits);+        candidates.extend(traits.iter().filter_map(|&trait_| {+            cx.tcx+                .associated_items(trait_)+                .find_by_name_and_namespace(cx.tcx, Ident::with_dummy_span(item_name), ns, trait_)+                .map(|assoc| (assoc.def_id, assoc.kind))+        }));+    }+    // FIXME: warn about ambiguity+    debug!("the candidates were {:?}", candidates);+    candidates.pop().map(|(_, kind)| kind)+}++thread_local! {+    // map<type, set<trait>>+    static TYPE_TRAIT_CACHE: RefCell<FxHashMap<DefId, Rc<FxHashSet<DefId>>>> = RefCell::new(FxHashMap::default());

Couldn't this be a field of DocContext?

jyn514

comment created time in 3 days

Pull request review commentrust-lang/rust

Fix intra-doc links for associated items

 impl<'a, 'tcx> LinkCollector<'a, 'tcx> {                         } else {                             Ok((ty_res, Some(format!("{}.{}", kind, item_name))))                         }-                    } else {-                        self.variant_field(path_str, current_item, module_id)-                    }+                    }),+                _ => None,+            };+            res.unwrap_or_else(|| {+                if ns == Namespace::ValueNS {+                    self.variant_field(path_str, current_item, module_id)+                } else {+                    Err(ErrorKind::ResolutionFailure)                 }-                _ => self.variant_field(path_str, current_item, module_id),-            }+            })         } else {             debug!("attempting to resolve item without parent module: {}", path_str);             Err(ErrorKind::ResolutionFailure)         }     } } +fn resolve_associated_trait_item(+    did: DefId,+    item_name: Symbol,+    ns: Namespace,+    cx: &DocContext<'_>,+) -> Option<ty::AssocKind> {+    let ty = cx.tcx.type_of(did);+    // First consider automatic impls: `impl From<T> for T`+    let implicit_impls = crate::clean::get_auto_trait_and_blanket_impls(cx, ty, did);+    let mut candidates: Vec<_> = implicit_impls+        .flat_map(|impl_outer| {+            match impl_outer.inner {+                ImplItem(impl_) => {+                    debug!("considering auto or blanket impl for trait {:?}", impl_.trait_);+                    // Give precedence to methods that were overridden+                    if !impl_.provided_trait_methods.contains(&*item_name.as_str()) {+                        let mut items = impl_.items.into_iter().filter_map(|assoc| {+                            if assoc.name.as_deref() != Some(&*item_name.as_str()) {+                                return None;+                            }+                            let kind = assoc+                                .inner+                                .as_assoc_kind()+                                .expect("inner items for a trait should be associated items");+                            if kind.namespace() != ns {+                                return None;+                            }++                            trace!("considering associated item {:?}", assoc.inner);+                            // We have a slight issue: normal methods come from `clean` types,+                            // but provided methods come directly from `tcx`.+                            // Fortunately, we don't need the whole method, we just need to know+                            // what kind of associated item it is.+                            Some((assoc.def_id, kind))+                        });+                        let assoc = items.next();+                        debug_assert_eq!(items.count(), 0);+                        assoc+                    } else {+                        // These are provided methods or default types:+                        // ```+                        // trait T {+                        //   type A = usize;+                        //   fn has_default() -> A { 0 }+                        // }+                        // ```+                        let trait_ = impl_.trait_.unwrap().def_id().unwrap();+                        cx.tcx+                            .associated_items(trait_)+                            .find_by_name_and_namespace(+                                cx.tcx,+                                Ident::with_dummy_span(item_name),+                                ns,+                                trait_,+                            )+                            .map(|assoc| (assoc.def_id, assoc.kind))+                    }+                }+                _ => panic!("get_impls returned something that wasn't an impl"),+            }+        })+        .collect();++    // Next consider explicit impls: `impl MyTrait for MyType`+    // Give precedence to inherent impls.+    if candidates.is_empty() {+        // FIXME: As an optimization, this could only search traits in scope.

That's not an optimization, it's a behavior change. Are you sure we should be resolving items from traits even if they're not in scope?

jyn514

comment created time in 3 days

issue commentrust-lang/rust

Make `pub` in a binary be equivalent to `pub(crate)`

It would make sense to do this for staticlibs and cydlibs as well.

jhpratt

comment created time in 5 days

pull request commentrust-lang/rust

Don't print "const" keyword on non-nightly build if rustc_const_unstable is used on the item

is_min_const_fn already checks for rustc_const_unstable. The issue in #74579 is that rustdoc isn't calling is_min_const_fn for methods from the current crate. That should probably happen around https://github.com/rust-lang/rust/blob/21867225a74d3b07c2b65e32c67f45197db36896/src/librustdoc/clean/mod.rs#L883 overriding the constness field of header like is done elsewhere.

GuillaumeGomez

comment created time in 6 days

pull request commentrust-lang/rust

Doc alias checks: ensure only items appearing in search index can use it

check_mod_attrs is called here: https://github.com/rust-lang/rust/blob/21867225a74d3b07c2b65e32c67f45197db36896/src/librustc_interface/passes.rs#L847

so I tested adding:

for &module in tcx.hir().krate().modules.keys() {
    let local_def_id = tcx.hir().local_def_id(module);
    tcx.ensure().check_mod_attrs(local_def_id);
};

just after https://github.com/rust-lang/rust/blob/21867225a74d3b07c2b65e32c67f45197db36896/src/librustdoc/core.rs#L460-L462 and it seems to work just fine. I don't think that requires typeck but I could be wrong.

GuillaumeGomez

comment created time in 6 days

issue commentrust-lang/rust

Rustdoc generates invalid links for reexported types

rustdoc will inline reexports from external crates unless you add #[doc(no_inline)] to the pub use statement. I'd recommend doing that here and for preludes in general.

As for the broken links that's just because they're relative URLs: https://docs.rs/embedded-graphics/0.6.2/src/embedded_graphics/style/text_style.rs.html#121-128 and the page is being generated in a different location. Using #[doc(no_inline)] would avoid the issue but using intra-doc links should allow rustdoc to generate working links in this case.

bugadani

comment created time in 6 days

pull request commentrust-lang/rust

Doc alias checks: ensure only items appearing in search index can use it

Ideally this check would be done inside rustc with the other checks. Unfortunately I think #73566 meant that the checks moved in #74148 no longer run in rustdoc. That should have bee caught by CI but the test was moved rather than copied.

Assuming it's possible to get the check_mod_attrs pass running in rustdoc again then we should do that and move the checks from this PR there.

GuillaumeGomez

comment created time in 7 days

pull request commentrust-lang/rust

Stabilize intra-doc links

I still feel as though this has only just been fully implemented so stabilization is premature. In fact #74489 proves the implementation isn't finished.

I would like to see more use in std to hopefully identify more issues. Ideally all of std would be converted but that will take a while. How about opening a tracking issue for converting all of the std docs to use intra-doc links?

I think the issue of linking to primitive types like slice could be fixed before stabilization. How about adding a new "namespace" primitive@ to allow linking to all primitives? For example primitive@slice would link to the slice page. This would allow removing the workaround in #74078.

Do we actually need so many disambiguators? We have both mod@ and module@, fn@ and function@ but for some reason const@ but no constant@. Could we get away with only having the ones that are actually keywords?

I do find it a bit odd that struct@ will resolve anything in the type namespace including things like mods and traits. Are people sure that's the behavior we want? I'm not aware of any reason we shouldn't be strict here.

The intra_doc_link_resolution_failure lint needs to be renamed to follow the lint name guidelines by making it plural.

@rfcbot concern lint-name

The docs for intra_doc_link_resolution_failure need to be updated. The "nightly-only" comment needs to be removed. It could do with a link to the docs for intra-doc links and vica versa. The docs could also be expanded to list the various ways in which the lint can fire.

@rfcbot concern lint-docs

For some reason the code for the missing_doc_code_examples lint is triggered in the intra-doc link code: https://github.com/rust-lang/rust/blob/e8b55a4ad230ebec762fdfc4f241ba98a98560af/src/librustdoc/passes/collect_intra_doc_links.rs#L511

Are people aware of this? The effect of this is that stabilizing intra-doc links is also stabilizing that lint. Assuming that that is not intentional, that lint needs to be stabilized separately.

@rfcbot concern missing_doc_code_examples

Manishearth

comment created time in 8 days

pull request commentrust-lang/rust

mv std libs to library/

I don't think it makes sense to move rustc_demangle

rustc_demangle is on crates.io so isn't relevant here.

Also, there was some discussion about rustc_std_workspace_* crates above, and it seems like we want to keep them with the build system for now, though I may have misunderstood.

rustc_std_workspace_* are part of the rust-src component so IMO should be moved to library as well.

The only other crate in rust-src that hasn't been moved is build_helper but it looks like that isn't a dependency of std anymore so should just be removed from rust-src.

mark-i-m

comment created time in 15 days

Pull request review commentrust-lang/rust

mv std libs to library/

 	path = src/doc/rust-by-example 	url = https://github.com/rust-lang/rust-by-example.git [submodule "src/stdarch"]
[submodule "library/stdarch"]
mark-i-m

comment created time in 15 days

pull request commentrust-lang/rust

Do not clobber RUSTDOCFLAGS

From CI:

error[E0369]: binary operation `==` cannot be applied to type `impl AsRef<OsStr>`
    --> src/bootstrap/builder.rs:1474:9
     |
1474 |         assert_ne!(key, "RUSTFLAGS");
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |         |
     |         impl AsRef<OsStr>
     |         &str
     |
     = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

r=me with the above issue fixed.

Mark-Simulacrum

comment created time in 17 days

issue commentrust-lang/rust

nightly-rustc docs no longer document private items

This is the issue I pointed out in the second part of https://github.com/rust-lang/rust/pull/71670#discussion_r455875330. I clearly didn't explain the issue well enough.

SNCPlay42

comment created time in 17 days

pull request commentrust-lang/rust

More intra-doc links, add explicit exception list to linkchecker

Fixes #32553

This won't actually fix #32553 because it is about the missing Methods from Deref<Target=str> section on the alloc::string::String page. This may be able to fix the broken links that were caused by that though.

Manishearth

comment created time in 17 days

pull request commentrust-lang/rust

Use intra-doc-link to fix broken links

This may fix #32553.

This won't actually fix #32553 because it is about the missing Methods from Deref<Target=str> section on the alloc::string::String page. This may be able to fix the broken links that were caused by that though.

lzutao

comment created time in 17 days

pull request commentrust-lang/rust

Use intra-doc links in `str` and `BTreeSet`

Fixes #32129, fixes #32130

Those issues can't be closed until the exceptions in linkchecker are removed:

https://github.com/rust-lang/rust/blob/d3df8512d2c2afc6d2e7d8b5b951dd7f2ad77b02/src/tools/linkchecker/main.rs#L122-L127 and https://github.com/rust-lang/rust/blob/d3df8512d2c2afc6d2e7d8b5b951dd7f2ad77b02/src/tools/linkchecker/main.rs#L132-L141

Manishearth

comment created time in 18 days

Pull request review commentrust-lang/rust

consult dlerror() only if a dl*() call fails

 mod dl {             // dlerror isn't thread safe, so we need to lock around this entire             // sequence             let _guard = (*LOCK).lock();++            // dlerror reports the most recent failure that occured during a+            // dynamic linking operation and then clears that error; we call+            // once in advance of our operation in an attempt to discard any+            // stale prior error report that may exist:             let _old_error = libc::dlerror();

Is this call still needed? Surely any prior error will be replaced if there's a new error.

jclulow

comment created time in 18 days

pull request commentrust-lang/team

Add jyn514 and Manishearth to the rustdoc team

Fine with me 👍

GuillaumeGomez

comment created time in 19 days

pull request commentrust-lang/rust

Reintroduce spotlight / "important traits" feature

Looks good now, glad it was an easy fix.

Manishearth

comment created time in 20 days

Pull request review commentrust-lang/rust

Enforce even more the code blocks attributes check through rustdoc

 impl<'a> Builder<'a> {             if mode == Mode::Std && compiler.stage == 0 && self.config.incremental {                 rustflags.arg("-Aunused-attributes");             }+            rustdocflags.arg("-Dinvalid_codeblock_attributes");

That would be problematic because of the broken links for the moment.

What broken links? There shouldn't be any and passing -Dwarnings will prevent new ones being added. I can understand not wanting to pass -Dwarnings for the compiler docs so if that's the concern then just denying invalid_codeblock_attributes for now is fine. We should definitely pass -Dwarnings when building at least the std docs at some point though.

Also setting rustdocflags here will override the setting from https://github.com/rust-lang/rust/blob/4cd0ee9343da86d9770bf0a514a682d240e0dce8/src/bootstrap/doc.rs#L530-L534 and https://github.com/rust-lang/rust/blob/4cd0ee9343da86d9770bf0a514a682d240e0dce8/src/bootstrap/doc.rs#L627

Those need to be changed to use the same mechanism for setting rustdocflags as is used here.

GuillaumeGomez

comment created time in 20 days

Pull request review commentrust-lang/rust

Enforce even more the code blocks attributes check through rustdoc

 impl<'a> Builder<'a> {             .env("CFG_RELEASE_CHANNEL", &self.config.channel)             .env("RUSTDOC_REAL", self.rustdoc(compiler))             .env("RUSTDOC_CRATE_VERSION", self.rust_version())-            .env("RUSTC_BOOTSTRAP", "1");+            .env("RUSTC_BOOTSTRAP", "1")+            .arg("-Dinvalid_codeblock_attributes");+        if self.config.deny_warnings {+            cmd.arg("-Dwarnings");+        }

What else is it used for? I can only see rustdoc_cmd being used for markdown files.

GuillaumeGomez

comment created time in 20 days

pull request commentrust-lang/rust

Don't run `everybody_loops` for rustdoc; instead ignore resolution errors

@ollie27 do you mind looking at this to see if the tradeoffs are acceptable? #73566 (comment)

Yeah that all looks good to me 👍.

jyn514

comment created time in 20 days

pull request commentrust-lang/rust

Don't pollute docs/suggestions with libstd deps

If this is holding up other work and people are okay with the docs regression especially with the compiler docs then I'm not going to block this.

@bors r=estebank,GuillaumeGomez

alexcrichton

comment created time in 20 days

pull request commentrust-lang/rust

rustdoc: glue tokens before highlighting

I didn't realize that that bug was present in the past, in which case I agree that this is fine.

@bors r=ollie27,GuillaumeGomez

euclio

comment created time in 20 days

pull request commentrust-lang/rust

Reintroduce spotlight / "important traits" feature

I'm really not a fan of reintroducing bugs but I guess it's not the end of the world. There's even an old issue still open (#55082) for the impls that aren't applicable.

Could the issue with free functions I pointed out in https://github.com/rust-lang/rust/pull/74370#pullrequestreview-449195537 be fixed though? That wasn't an issue with the old implementation. If it's too difficult to fix then the important traits feature could be disabled for those functions for now.

Manishearth

comment created time in 20 days

Pull request review commentrust-lang/rust

Reintroduce spotlight / "important traits" feature

 fn should_render_item(item: &clean::Item, deref_mut_: bool) -> bool {     } } +fn spotlight_decl(decl: &clean::FnDecl) -> String {+    let mut out = Buffer::html();+    let mut trait_ = String::new();++    if let Some(did) = decl.output.def_id() {+        let c = cache();+        if let Some(impls) = c.impls.get(&did) {

This isn't a good way to find applicable impls because it doesn't take into account things like generic parameters and mutability. For example:

image

and

image

I'd imagine this will need to use a mechanism similar to how auto trait and blankets impls are found.

Manishearth

comment created time in 21 days

issue commentrust-lang/rust

HTML generated for code blocks can be improved (and shortened)

#73807 might fix this.

GuillaumeGomez

comment created time in 21 days

pull request commentrust-lang/rust

rustdoc: glue tokens before highlighting

Sorry for the delay.

Unfortunately this doesn't completely fix the issue. There are cases where tokens shouldn't be glued together for example:

Before this PR:

image

After this PR:

image

I'm tempted to say we should merge this anyway unless there's an easy way to fix the above because in most cases this is an improvement. @GuillaumeGomez what do you think?

euclio

comment created time in 21 days

pull request commentrust-lang/rust

rustdoc: Rename internal API fns to `into_string`

@bors r-

failed on CI:

error[E0599]: no method named `to_string` found for struct `html::markdown::MarkdownHtml<'_>` in the current scope
    --> src/librustdoc/html/render.rs:2334:18
     |
2334 |                   .to_string()
     |                    ^^^^^^^^^ help: there is an associated function with a similar name: `into_string`
     | 
    ::: src/librustdoc/html/markdown.rs:73:1
     |
73   | / pub struct MarkdownHtml<'a>(
74   | |     pub &'a str,
75   | |     pub &'a mut IdMap,
76   | |     pub ErrorCodes,
77   | |     pub Edition,
78   | |     pub &'a Option<Playground>,
79   | | );
     | |  -
     | |  |
     | |  method `to_string` not found for this
     | |__doesn't satisfy `_: std::fmt::Display`
     |    doesn't satisfy `_: std::string::ToString`
     |
     = note: the method `to_string` exists but the following trait bounds were not satisfied:
             `html::markdown::MarkdownHtml<'_>: std::fmt::Display`
             which is required by `html::markdown::MarkdownHtml<'_>: std::string::ToString`

error: aborting due to previous error

lzutao

comment created time in 21 days

Pull request review commentrust-lang/rust

Do not render unstable items for rustc doc

-// compile-flags: -Z force-unstable-if-unmarked--// @matches internal/index.html '//*[@class="docblock-short"]/span[@class="stab internal"]' \-//      'Internal'

This test should be modified to check that the unstable marker is not added for rustc_private.

lzutao

comment created time in 21 days

Pull request review commentrust-lang/rust

Do not render unstable items for rustc doc

 impl ExternalHtml {         let bc = format!(             "{}{}",             bc,-            Markdown(&m_bc, &[], id_map, codes, edition, playground).to_string()+            Markdown(&m_bc, &[], id_map, codes, edition, playground).into_string()

Can this change be done in a separate PR? It seems unrelated to this one.

lzutao

comment created time in 21 days

Pull request review commentrust-lang/rust

Enforce even more the code blocks attributes check through rustdoc

 impl<'a> Builder<'a> {             if mode == Mode::Std && compiler.stage == 0 && self.config.incremental {                 rustflags.arg("-Aunused-attributes");             }+            rustdocflags.arg("-Dinvalid_codeblock_attributes");

Yeah, I was mistaken. We should really just start adding -Dwarnings to rustdocflags as well as rustflags.

GuillaumeGomez

comment created time in 23 days

Pull request review commentrust-lang/rust

Enforce even more the code blocks attributes check through rustdoc

 impl<'a> Builder<'a> {             if mode == Mode::Std && compiler.stage == 0 && self.config.incremental {                 rustflags.arg("-Aunused-attributes");             }+            rustdocflags.arg("-Dinvalid_codeblock_attributes");

invalid_codeblock_attributes is a warn by default lint so there's no reason to pass this. The -Dwarnings above already makes it deny.

GuillaumeGomez

comment created time in 23 days

Pull request review commentrust-lang/rust

Enforce even more the code blocks attributes check through rustdoc

 pub fn run_core(options: RustdocOptions) -> (clean::Crate, RenderInfo, RenderOpt     let missing_doc_example = rustc_lint::builtin::MISSING_DOC_CODE_EXAMPLES.name;     let private_doc_tests = rustc_lint::builtin::PRIVATE_DOC_TESTS.name;     let no_crate_level_docs = rustc_lint::builtin::MISSING_CRATE_LEVEL_DOCS.name;-    let invalid_codeblock_attribute_name = rustc_lint::builtin::INVALID_CODEBLOCK_ATTRIBUTES.name;+    let invalid_codeblock_attributes_name = rustc_lint::builtin::INVALID_CODEBLOCK_ATTRIBUTES.name;

Good catch!

GuillaumeGomez

comment created time in 23 days

Pull request review commentrust-lang/rust

Enforce even more the code blocks attributes check through rustdoc

 impl<'a> Builder<'a> {             .env("CFG_RELEASE_CHANNEL", &self.config.channel)             .env("RUSTDOC_REAL", self.rustdoc(compiler))             .env("RUSTDOC_CRATE_VERSION", self.rust_version())-            .env("RUSTC_BOOTSTRAP", "1");+            .env("RUSTC_BOOTSTRAP", "1")+            .arg("-Dinvalid_codeblock_attributes");+        if self.config.deny_warnings {+            cmd.arg("-Dwarnings");+        }

rustdoc ignores lints when run on markdown files so this has no effect.

GuillaumeGomez

comment created time in 23 days

pull request commentrust-lang/rust

Don't pollute docs/suggestions with libstd deps

One option would be to invert #[doc(masked)], i.e. mask every crate that doesn't have a special attribute applied. That way std would only need to add an attribute for core and alloc.

Another option would be to tell rustdoc to hide anything from crates it can't generate local relative links to when documenting std. That would have the same effect.

Long term I wonder if #44663 could be used to resolve this.

I guess we can merge this temporarily if it helps unblock things though.

The trait itself is not linked (it's just text), but one of the methods on that trait has a "Read more" link which is a dead link.

That's very much a rustdoc bug, I've filed #74222.

alexcrichton

comment created time in a month

issue openedrust-lang/rust

rustdoc generates broken "Read more" links when the destination crate doesn't have a URL

I tried this code:

foo.rs:

#![crate_type = "rlib"]
pub struct FooStruct;
pub trait FooTrait {
    /// docs
    ///
    /// more docs
    fn foo_method();
}
impl FooTrait for FooStruct {
    fn foo_method() {}
}

bar.rs:

extern crate foo;
pub use foo::FooStruct;

running rustc foo.rs && rustdoc -L . bar.rs so only bar is documented.

I expected to see this happen:

When the docs for bar are documented the page for FooStruct shouldn't contain any broken "Read more" links.

Instead, this happened:

The "Read more" link for foo_method on the page for FooStruct points to #tymethod.foo_method which doesn't go anywhere. It should point to the documentation for FooTrait but as that page doesn't exist the "Read more" link shouldn't exist at all. The link works fine if docs for foo are also generated or pub use foo::FooTrait; is added to bar.rs.

Meta

rustc --version --verbose:

rustc 1.46.0-nightly (5db778aff 2020-07-09)
binary: rustc
commit-hash: 5db778affee7c6600c8e7a177c48282dab3f6292
commit-date: 2020-07-09
host: x86_64-pc-windows-msvc
release: 1.46.0-nightly
LLVM version: 10.0

created time in a month

pull request commentrust-lang/rust

Don't pollute docs/suggestions with libstd deps

@ollie27 this is a problem not only for direct dependencies but also transitive dependencies of the standard library. For example libstd does not actually depend directly on gimli, it's transitively through other crates gimli is pulled in.

Is there any reason gimli can't be added a dependency to std in order to add #[doc(masked)]? It's not pretty but it's the current mechanism to handle this.

alexcrichton

comment created time in a month

issue commentrust-lang/rust

Tracking issue for RFC 1946 - intra-rustdoc links

* #74070 -> #73566 -> #73101 -> #73365

Once that is done, we can make a stabilization PR 🎉 .

Once that is done we'll have an initial functional implementation. The next step is testing it. A big part of that will be to start using it in the std docs and seeing if it can fix the issues it was designed for (#32129, #32130).

nrc

comment created time in a month

pull request commentrust-lang/rust

Don't pollute docs/suggestions with libstd deps

rustdoc has a #[doc(masked)] attribute for this issue. Adding #[doc(masked)] extern crate gimli; lines to std for all of the dependencies should fix the docs part of this.

alexcrichton

comment created time in a month

issue commentrust-lang/rust

rustdoc incorrectly handles ##

A lint would be overly complicated for this. The behavior is documented at https://doc.rust-lang.org/nightly/rustdoc/documentation-tests.html#hiding-portions-of-the-example but maybe it can be improved to make it clear that you need a space after the hash for a line to be hidden.

lcnr

comment created time in a month

pull request commentrust-lang/rust

Allow for parentheses after macro intra-doc-links

Shouldn't a test be added for this?

Manishearth

comment created time in a month

delete branch ollie27/rust

delete branch : rustdoc_invalid_codeblock_attributes_name

delete time in a month

pull request commentrust-lang/rust

Only add CFGuard on `windows-msvc` targets

Thanks @ollie27, do the new ui tests cover the cases you had in mind?

Yep, looks good.

ajpaverd

comment created time in a month

pull request commentrust-lang/rust

rustdoc: Rename invalid_codeblock_attribute lint to be plural

This will need to be backported to beta as that's the first version with this lint.

ollie27

comment created time in a month

PR opened rust-lang/rust

rustdoc: Rename invalid_codeblock_attribute lint to be plural

Lint names should be plural as per the lint naming conventions: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md#lints

r? @GuillaumeGomez

+14 -14

0 comment

9 changed files

pr created time in a month

push eventollie27/rust

Oliver Middleton

commit sha 56fb71786a77706cefec8170bd06a5c990493b2b

rustdoc: Rename invalid_codeblock_attribute lint to be plural

view details

push time in a month

create barnchollie27/rust

branch : rustdoc_invalid_codeblock_attributes_name

created branch time in a month

pull request commentrust-lang/rust

Doc alias checks: ensure only items appearing in search index can use it

The search index also doesn't include associated types and consts in trait impls so we'll need to error on those too. I'm not actually sure why they're not included though.

GuillaumeGomez

comment created time in a month

issue commentrust-lang/rust

Add missing checks for #[doc(alias = "")]

I remember you telling that you'd prefer this check in rustc directly instead of rustdoc. I can move things there, just wanted to check one last time before doing it.

Yeah, rustc validates some attributes in https://github.com/rust-lang/rust/blob/master/src/librustc_passes/check_attr.rs and it might make sense to validate the #[doc] attribute there as well.

GuillaumeGomez

comment created time in a month

pull request commentrust-lang/rust

Only add CFGuard on `windows-msvc` targets

I think this could do with a couple of ui tests like:

// run-pass
// compile-flags: -Z control-flow-guard
// ignore-msvc

fn main() {
    println!("Hello, world!");
}

and

// run-pass
// compile-flags: -Z control-flow-guard
// only-msvc

fn main() {
    println!("Hello, world!");
}

to make sure we're actually producing working binaries and the warning is printed when it should be.

ajpaverd

comment created time in a month

issue commentrust-lang/rust

__sync_val_compare_and_swap_ linker error

* to the highest number of bits that you can emulate up to 64,

It can actually go up to 128.

lights0123

comment created time in a month

issue commentrust-lang/rust

Add missing checks for #[doc(alias = "")]

You mentioned other checks too @ollie27 ?

We should reject #[doc(alias = "")] on items that don't actually appear in the search index such as extern blocks and impls.

GuillaumeGomez

comment created time in a month

pull request commentrust-lang/rust

Stabilize control-flow-guard codegen option

I tried compiling a simple hello world binary for none MSVC targets with -Zcontrol-flow-guard=y and it doesn't seem to be ignored. On x86_64-pc-windows-gnu along with the warning: Windows Control Flow Guard is not supported by this linker. message I'm getting an undefined reference to `__guard_dispatch_icall_fptr' error. On x86_64-unknown-linux-gnu rustc just segfaults. I can investigate further if needed but I assume we just need to make sure the cfguard module flag is only emitted when actually targeting windows-msvc.

ajpaverd

comment created time in a month

Pull request review commentrust-lang/rust

Use `str::strip_{prefix,suffix}` when possible

 enum Line<'a> { }  impl<'a> Line<'a> {+    fn from_str(s: &'a str) -> Self {+        let trimmed = s.trim();+        match trimmed.strip_prefix("#") {+            Some(tail) => match tail.strip_prefix("#") {+                // `##text` rendered as `#text`.+                Some(_) => Line::Shown(tail.into()),+                None => match tail.as_bytes() {+                    // `#` will be hidden.+                    [] => Line::Hidden(""),+                    // `# text` will be hidden.+                    [b' ' | b'\t', ..] => Line::Hidden(tail),

Also the old code would trim the space but this doesn't.

lzutao

comment created time in a month

pull request commentrust-lang/rust

Remove trait LengthAtMost32

The docs will also need to be updated, for example: https://github.com/rust-lang/rust/blob/0cd7ff7ddfb75a38dca81ad3e76b1e984129e939/src/libstd/primitive_docs.rs#L463-L483

kpp

comment created time in a month

Pull request review commentrust-lang/rust

Update RELEASES.md for 1.45.0

+Version 1.45.0 (2020-07-16)+==========================++Language+--------+- [Out of range float to int conversions using `as` has been defined as a saturating+  conversion.][71269] This was previously undefined behaviour, but you can use the+   `{f64, f32}::to_int_unchecked` methods to continue using the current behaviour, which+   may be desirable in rare performance sensitive situations.+- [`mem::Discriminant<T>` now uses `T`'s discriminant type instead of always+  using `u64`.][70705]+- [Function like procedural macros can now be used in expression, pattern, and  statement+  positions.][68717] This now means you can now use a function-like procedural macro+  anywhere you can use a declarative (`macro_rules!`) macros.++Compiler+--------+- [You can now override individual target features through the `target-feature`+  flag.][72094] E.g. `-C target-feature=+avx2 -C target-feature=+fma` is now+  equivalent to `-C target-feature=+avx2,+fma`.+- [Added the `force-unwind-tables` flag.][69984] This option allows+  rustc to always generate unwind tables regardless of panic strategy.+- [Added the `embed-bitcode` flag.][71716] This codegen flag allows rustc+  to include LLVM bitcode into generated `rlib`s (this is on by default).+- [Added the `tiny` value to the `code-model` codegen flag.][72397]+- [Added tier 3 support\* for the `mipsel-sony-psp` target.][72062]+- [Added tier 3 support for the `thumbv7a-uwp-windows-msvc` target.][72133]++\* Refer to Rust's [platform support page][forge-platform-support] for more+information on Rust's tiered platform support.+++Libraries+---------+- [`net::{SocketAddr, SocketAddrV4, SocketAddrV6}` now implements `PartialOrd`+  and `Ord`.][72239]+- [`proc_macro::TokenStream` now implements `Default`.][72234]+- [You can now use `char` with+  `ops::{Range, RangeFrom, RangeFull, RangeInclusive, RangeTo}`.][72413] e.g.+  You can now write the following;+  ```rust+  for ch in 'a'..='z' {+      print!("{}", ch);+  }+  println!();+  // Prints "abcdefghijklmnopqrstuvwxyz"+  ```+- [`OsString` now implements `FromStr`.][71662]+- [The `saturating_neg` method as been added to all signed integer primitive+  types, and the `saturating_abs` method has been added for all integer+  primitive types.][71886]+- [`Arc<T>`, `Rc<T>` now implement  `From<Cow<'_, T>>`, and `Box` now+  implements `From<Cow>` when `T` is `[T: Copy]`, `str`, `CStr`, `OsStr`,+  or `Path`.][71447]+- [`Box<[T]>` now implements `From<[T; N]> `.][71095]+- [`BitOr` and `BitOrAssign` are implemented for all `NonZero`+  integer types.][69813]+- [The `fetch_min`, and `fetch_max` methods have been added to all atomic+  integer types.][72324]+- [The `fetch_update` method has been added to all atomic integer types.][71843]++Stabilized APIs+---------------+- [`Arc::as_ptr`]+- [`BTreeMap::remove_entry`]+- [`Rc::as_ptr`]+- [`rc::Weak::as_ptr`]+- [`rc::Weak::from_raw`]+- [`rc::Weak::into_raw`]+- [`str::strip_prefix`]+- [`str::strip_suffix`]+- [`sync::Weak::as_ptr`]+- [`sync::Weak::from_raw`]+- [`sync::Weak::into_raw`]+- [`char::UNICODE_VERSION`]+- [`Span::resolved_at`]+- [`Span::located_at`]+- [`Span::mixed_site`]+- [`unix::process::CommandExt::arg0`]++Cargo+-----++Misc+----+- [Rustdoc now supports strikethrough text in Markdown.][71928] E.g.+  `~~outdated information~~` becomes "~~outdated information~~".+- [Added a emoji to Rustdoc's deprecated API message.][72014]++Compatibility Notes+-------------------+- [Trying to self initialize a static value (that is creating a value using+  itself) is unsound and now causes a compile error.][71140]+- [`f32::powi` now returns a slightly different value on Windows.][73420]+  This is due to changes in LLVM's intrinsics which `f32::powi` uses.
- [`{f32, f64}::powi` now returns a slightly different value on Windows.][73420]
  This is due to changes in LLVM's intrinsics which `{f32, f64}::powi` uses.
XAMPPRocky

comment created time in a month

pull request commentrust-lang/rust

[rustdoc] Page hash handling

So I guess we're good? The <code> should never have had ids in the first place (and the reason is now very likely lost in a far away past).

We have git blame... As I said, the IDs were added to <span>s in #35236 and moved to the <code> tags in #55798.

FWIW I agree with removing these, but if we're going to remove features we should make some effort to help migrate existing users like RLS. We should also fully revert #35236 not just part of it.

GuillaumeGomez

comment created time in a month

Pull request review commentrust-lang/rust

Update RELEASES.md for 1.45.0

+Version 1.45.0 (2020-07-16)+==========================++Language+--------+- [Out of range float to int conversions using `as` has been defined as a saturating+  conversion.][71269] This was previously undefined behaviour, but you can use the+   `{f64, f32}::to_int_unchecked` methods to continue using the current behaviour, which+   may be desirable in rare performance sensitive situations.+- [`mem::Discriminant<T>` now uses `T`'s discriminant type instead of always+  using `u64`.][70705]+- [Function like procedural macros can now be used in expression, pattern, and  statement+  positions.][68717] This now means you can now use a function-like procedural macro+  anywhere you can use a declarative (`macro_rules!`) macros.++Compiler+--------+- [You can now override individual target features through the `target-feature`+  flag.][72094] E.g. `-C target-feature=+avx2 -C target-feature=+fma` is now+  equivalent to `-C target-feature=+avx2,+fma`.+- [Added the `force-unwind-tables` flag.][69984] This option allows+  rustc to always generate unwind tables regardless of panic strategy.+- [Added the `embed-bitcode` flag.][71716] This codegen flag allows rustc+  to include LLVM bitcode into generated `rlib`s (this is on by default).+- [Added the `tiny` value to the `code-model` codegen flag.][72397]+- [Added tier 3 support\* for the `mipsel-sony-psp` target.][72062]+- [Added tier 3 support for the `thumbv7a-uwp-windows-msvc` target.][72133]++\* Refer to Rust's [platform support page][forge-platform-support] for more+information on Rust's tiered platform support.+++Libraries+---------+- [`net::{SocketAddr, SocketAddrV4, SocketAddrV6}` now implements `PartialOrd`+  and `Ord`.][72239]+- [`proc_macro::TokenStream` now implements `Default`.][72234]+- [You can now use `char` with+  `ops::{Range, RangeFrom, RangeFull, RangeInclusive, RangeTo}`.][72413] e.g.+  You can now write the following;+  ```rust+  for ch in 'a'..='z' {+      print!("{}", ch);+  }+  println!();+  // Prints "abcdefghijklmnopqrstuvwxyz"+  ```+- [`OsString` now implements `FromStr`.][71662]+- [The `saturating_neg` method as been added to all signed integer primitive+  types, and the `saturating_abs` method has been added for all integer+  primitive types.][71886]+- [`Arc<T>`, `Rc<T>` now implement  `From<Cow<'_, T>>`, and `Box` now+  implements `From<Cow>` when `T` is `[T: Copy]`, `str`, `CStr`, `OsStr`,+  or `Path`.][71447]+- [`Box<[T]>` now implements `From<[T; N]> `.][71095]+- [`BitOr` and `BitOrAssign` are implemented for all `NonZero`+  integer types.][69813]+- [The `fetch_min`, and `fetch_max` methods have been added to all atomic+  integer types.][72324]+- [The `fetch_update` method has been added to all atomic integer types.][71843]++Stabilized APIs+---------------+- [`Arc::as_ptr`]+- [`BTreeMap::remove_entry`]+- [`BufReader::capacity`]+- [`BufWriter::capacity`]+- [`Rc::as_ptr`]+- [`rc::Weak::as_ptr`]+- [`rc::Weak::from_raw`]+- [`rc::Weak::into_raw`]+- [`str::strip_prefix`]+- [`str::strip_suffix`]+- [`sync::Weak::as_ptr`]+- [`sync::Weak::from_raw`]+- [`sync::Weak::into_raw`]+- [`char::UNICODE_VERSION`]+- [`Span::resolved_at`]+- [`Span::located_at`]+- [`Span::mixed_site`]+- [`unix::process::CommandExt::arg0`]++Cargo+-----++Misc+----+- [Rustdoc now supports strikethrough text in Markdown.][71928] E.g.+  `~~outdated information~~` becomes "~~outdated information~~".+- [Added a emoji to Rustdoc's deprecated API message.][72014]++Compatibility Notes+-------------------+- [Trying to self initialize a static value (that is creating a value using+  itself) is unsound and now causes a compile error.][71140]+- [`f32::powi` now returns a slightly higher precision value on Windows.][73420]

It's not "higher precision", sometimes it might be more accurate but sometimes not. The change also affected f64.

XAMPPRocky

comment created time in a month

pull request commentrust-lang/rust

[rustdoc] Page hash handling

The extra IDs are part of #35236. To remove them we have to be sure that nothing is still using them. For example it looks like RLS is: https://github.com/rust-lang/rls/blob/fb46b914c11b06828680cb526e2abe9e1d69b868/rls-analysis/src/lib.rs#L500

GuillaumeGomez

comment created time in a month

issue closedrust-lang/rust

Documentation for Iterator::step_by missing `where Self: ?Sized` bound

https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.step_by

https://doc.rust-lang.org/nightly/src/core/iter/traits/iterator.rs.html#391-396

The function has the following signature: fn step_by(self, step: usize) -> StepBy<Self> where Self: Sized, however the where bound does not show up in the stdlib docs.

I'm not sure what's going on here; I attempted to replicate the situation but a similarly defined trait method in a bare crate works just fine.

cc @GuillaumeGomez

closed time in a month

Manishearth

issue commentrust-lang/rust

Documentation for Iterator::step_by missing `where Self: ?Sized` bound

Duplicate of #24183

Manishearth

comment created time in a month

issue commentrust-lang/rust

f32::powi on Windows returns different results between 1.44 and 1.45 beta

Did anyone actually figure out why this change was made?

iliekturtles

comment created time in a month

delete branch ollie27/rust

delete branch : rustdoc_alias_filter

delete time in a month

issue commentrust-lang/rust

[rustdoc] ALIASES[crate] is undefined

#73644 should fix this.

lzutao

comment created time in a month

PR opened rust-lang/rust

rustdoc: Fix doc aliases with crate filtering

Fix a crash when searching for an alias contained in the currently selected filter crate.

Also remove alias search results for crates that should be filtered out.

The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected.

Needs to be backported to beta to fix the std docs.

Fixes #73620

r? @GuillaumeGomez

+55 -8

0 comment

6 changed files

pr created time in a month

create barnchollie27/rust

branch : rustdoc_alias_filter

created branch time in a month

push eventollie27/rust

Oliver Middleton

commit sha 478750c1db7dee93bc26bd9b84197f9f291492bb

rustdoc: Fix doc aliases with crate filtering Fix a crash when searching for an alias contained in the currently selected filter crate. Also remove alias search results for crates that should be filtered out. The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected.

view details

push time in a month

issue commentrust-lang/rust

[rustdoc] ALIASES[crate] is undefined

It looks like it fails when you have a crate filter selected. Almost certainly caused by #71724 (cc @GuillaumeGomez).

lzutao

comment created time in a month

Pull request review commentrust-lang/rust

add missing doc links

 pub fn size_of_val<T: ?Sized>(val: &T) -> usize { ///     - an (unstable) [extern type], then this function is always safe to ///       call, but may panic or otherwise return the wrong value, as the ///       extern type's layout is not known. This is the same behavior as-///       [`size_of_val`] on a reference to an extern type tail.+///       [`size_of_val`] on a reference to a type with extern type tail. ///     - otherwise, it is conservatively not allowed to call this function. /// /// [slice]: ../../std/primitive.slice.html /// [trait object]: ../../book/ch17-02-trait-objects.html /// [extern type]: ../../unstable-book/language-features/extern-types.html+/// [`size_of_val`]: ../../core/mem/fn.size_of_val.html

It's #65983. The intra-doc link feature isn't ready for use in std yet.

RalfJung

comment created time in a month

pull request commentrust-lang/rust

Enforce doc alias check

Sorry for the delay. This is a good start. There's a lot more validation to do and it should probably be done inside rustc but for now let's get this merged at least for the test.

@bors r+ rollup

GuillaumeGomez

comment created time in 2 months

pull request commentrust-lang/rust

mv std libs to std/

Will the name part go away either if we remove the core vs libcore mismatch?

The lib name defaults to the package name so it can already be removed.

mark-i-m

comment created time in 2 months

pull request commentrust-lang/rust

mv std libs to std/

How about getting rid of the lib prefixes (e.g. libcore -> core) while we're at it?

mark-i-m

comment created time in 2 months

issue commentrust-lang/rust

f32::powi on Windows returns different results between 1.44 and 1.45 beta

Sounds like this issue should be closed as working as intended then?

I don't know. I think minor changes to the output of float operations between versions are technically allowed breakage but it would be nice to know why this change was made.

Given that powi seemed to be working fine before, does anyone know why https://reviews.llvm.org/D69013 was done?

iliekturtles

comment created time in 2 months

issue commentrust-lang/rust

__sync_val_compare_and_swap_ linker error

I think the correct solution is to add:

"max-atomic-width": 0

to the target JSON.

I don't think there's any bug here. If a target doesn't have native support for atomics then that either needs to be specified in the target JSON as above or implementations for the __sync_* functions need to be provided to emulate them.

lights0123

comment created time in 2 months

issue commentrust-lang/rust

f32::powi on Windows returns different results between 1.44 and 1.45 beta

Looking at the changes in assembly for powi on 1.44.0 we have:

	callq	__powisf2

but on beta that's replaced with:

	cvtsi2ss	%edx, %xmm1
	callq	powf

So LLVM has switched from calling the __powisf2 intrinsic from compiler-rt/compiler-builtins to calling powf. This looks like an intentional change from https://reviews.llvm.org/D69013 but it's not clear to me why that change was made.

iliekturtles

comment created time in 2 months

pull request commentrust-lang/rust

doc/rustdoc: Fix incorrect external_doc feature flag

Good catch.

@bors r+ rollup

spwilson2

comment created time in 2 months

issue closedrust-lang/rust

Rustdoc doesn't document impls within functions

You probably shouldn't be doing this, but given that you can, we should try and support it

pub struct Foo;

pub fn foo() {
    impl Foo {
        pub fn bar(&self) {
        }
    }
}

bar() is not documented, despite being usable globally. This might have to do with --everybody-loops?.

This works fine for trait implementations.

closed time in 2 months

Manishearth

issue commentrust-lang/rust

Rustdoc doesn't document impls within functions

Duplicate of #53763

Manishearth

comment created time in 2 months

issue closedrust-lang/rust

vec![].into_boxed_slice includes extraneous panicking code

This is a stable-to-stable regression between 1.43 and 1.44. Likely to do with allocator parametricity.

godbolt

pub fn new_boxed_slice(len: usize) -> Box<[u8]> {
    vec![0; len].into_boxed_slice()
}

1.43

example::new_boxed_slice:
        push    rbx
        mov     rbx, rdi
        test    rdi, rdi
        je      .LBB0_1
        mov     esi, 1
        mov     rdi, rbx
        call    qword ptr [rip + __rust_alloc_zeroed@GOTPCREL]
        test    rax, rax
        je      .LBB0_4
        mov     rdx, rbx
        pop     rbx
        ret
.LBB0_1:
        mov     eax, 1
        mov     rdx, rbx
        pop     rbx
        ret
.LBB0_4:
        mov     esi, 1
        mov     rdi, rbx
        call    qword ptr [rip + alloc::alloc::handle_alloc_error@GOTPCREL]
        ud2

1.44

core::ptr::drop_in_place:
        mov     rax, rdi
        mov     rdi, qword ptr [rdi]
        test    rdi, rdi
        je      .LBB0_2
        mov     rsi, qword ptr [rax + 8]
        test    rsi, rsi
        je      .LBB0_2
        mov     edx, 1
        jmp     qword ptr [rip + __rust_dealloc@GOTPCREL]
.LBB0_2:
        ret

alloc::raw_vec::RawVec<T,A>::allocate_in::{{closure}}:
        push    rax
        call    qword ptr [rip + alloc::alloc::handle_alloc_error@GOTPCREL]
        ud2

example::new_boxed_slice:
        push    rbx
        sub     rsp, 32
        mov     rbx, rdi
        test    rdi, rdi
        je      .LBB2_1
        mov     esi, 1
        mov     rdi, rbx
        call    qword ptr [rip + __rust_alloc_zeroed@GOTPCREL]
        test    rax, rax
        je      .LBB2_17
        mov     rsi, rbx
        jmp     .LBB2_4
.LBB2_1:
        mov     eax, 1
        xor     esi, esi
.LBB2_4:
        mov     qword ptr [rsp + 8], rax
        mov     qword ptr [rsp + 16], rsi
        mov     qword ptr [rsp + 24], rbx
        cmp     rsi, rbx
        je      .LBB2_14
        jb      .LBB2_10
        test    rsi, rsi
        je      .LBB2_14
        test    rax, rax
        je      .LBB2_14
        mov     edx, 1
        mov     rdi, rax
        test    rbx, rbx
        je      .LBB2_9
        mov     rcx, rbx
        call    qword ptr [rip + __rust_realloc@GOTPCREL]
        test    rax, rax
        jne     .LBB2_13
        mov     esi, 1
        mov     rdi, rbx
        call    qword ptr [rip + alloc::alloc::handle_alloc_error@GOTPCREL]
        ud2
.LBB2_9:
        call    qword ptr [rip + __rust_dealloc@GOTPCREL]
        mov     eax, 1
.LBB2_13:
        mov     qword ptr [rsp + 8], rax
        mov     qword ptr [rsp + 16], rbx
.LBB2_14:
        mov     rdx, rbx
        add     rsp, 32
        pop     rbx
        ret
.LBB2_17:
        mov     esi, 1
        mov     rdi, rbx
        call    alloc::raw_vec::RawVec<T,A>::allocate_in::{{closure}}
        ud2
.LBB2_10:
        lea     rdi, [rip + .L__unnamed_1]
        lea     rdx, [rip + .L__unnamed_2]
        mov     esi, 36
        call    qword ptr [rip + core::panicking::panic@GOTPCREL]
        ud2
        mov     rbx, rax
        lea     rdi, [rsp + 8]
        call    core::ptr::drop_in_place
        mov     rdi, rbx
        call    _Unwind_Resume@PLT
        ud2

.L__unnamed_1:
        .ascii  "Tried to shrink to a larger capacity"

.L__unnamed_3:
        .ascii  "/rustc/49cae55760da0a43428eba73abcb659bb70cf2e4/src/libcore/macros/mod.rs"

.L__unnamed_2:
        .quad   .L__unnamed_3
        .asciz  "I\000\000\000\000\000\000\000\"\000\000\000\t\000\000"

DW.ref.rust_eh_personality:
        .quad   rust_eh_personality

closed time in 2 months

CAD97

issue commentrust-lang/rust

vec![].into_boxed_slice includes extraneous panicking code

Duplicate of #71861

CAD97

comment created time in 2 months

create barnchollie27/rust

branch : rustdoc_src_files2

created branch time in 2 months

Pull request review commentrust-lang/rust

Export `#[inline] #[no_mangle]` fns in cdylibs and staticlibs

 fn codegen_fn_attrs(tcx: TyCtxt<'_>, id: DefId) -> CodegenFnAttrs {     codegen_fn_attrs } +fn inline_exportable(tcx: TyCtxt<'_>, def_id: DefId) -> bool {+    // Functions marked with #[inline] are only ever codegened+    // with "internal" linkage and are never exported unless we're+    // building a `staticlib` or `cdylib` and they are marked+    // `#[no_mangle]`.+    tcx.codegen_fn_attrs(def_id).flags.contains(CodegenFnAttrFlags::NO_MANGLE)+        && (tcx.sess.crate_types().contains(&CrateType::Cdylib)+            || tcx.sess.crate_types().contains(&CrateType::Staticlib))

Do we need to check the crate type here? Even when building rlibs we'll still need to codegen and export #[no_mangle] #[inline] items in case they're linked into a staticlib or cdylib.

doctorn

comment created time in 2 months

Pull request review commentrust-lang/rust

Export `#[inline] #[no_mangle]` fns in cdylibs and staticlibs

 fn codegen_fn_attrs(tcx: TyCtxt<'_>, id: DefId) -> CodegenFnAttrs {     codegen_fn_attrs } +fn inline_exportable(tcx: TyCtxt<'_>, def_id: DefId) -> bool {+    // Functions marked with #[inline] are only ever codegened+    // with "internal" linkage and are never exported unless we're+    // building a `staticlib` or `cdylib` and they are marked+    // `#[no_mangle]`.+    tcx.codegen_fn_attrs(def_id).flags.contains(CodegenFnAttrFlags::NO_MANGLE)

There is also #[export_name = "..."] and #[linkage = "..."] to consider so this should really be calling contains_extern_indicator.

doctorn

comment created time in 2 months

startedelectronicarts/CnC_Remastered_Collection

started time in 2 months

pull request commentrust-lang/rust

Tiny Vecs are dumb.

There is a dedicated issue for the growth strategy of Vec: #29931. This discussion should probably be happening there.

nnethercote

comment created time in 2 months

Pull request review commentrust-lang/rust

from_u32_unchecked: check validity when debug assertions are enabled

 pub fn from_u32(i: u32) -> Option<char> { #[inline] #[stable(feature = "char_from_unchecked", since = "1.5.0")] pub unsafe fn from_u32_unchecked(i: u32) -> char {-    transmute(i)+    if cfg!(debug_assertions) { char::from_u32(i).unwrap() } else { transmute(i) }

from_u32 ends up calling from_u32_unchecked so won't this result in an infinite recursion?

RalfJung

comment created time in 2 months

Pull request review commentrust-lang/rust

Clean up rustdoc source code

 use std::fs; use std::io; use std::path::Path;+use std::string::ToString;

@GuillaumeGomez did you miss this comment?

GuillaumeGomez

comment created time in 2 months

pull request commentrust-lang/rust

Doc alias improvements

Well, for me it's important to keep one change per commit. It makes the git history easier to follow.

I agree but that's not what we have. Take for example cf41b1d3a5fc5e4c209ab101b159095178dea916 which adds pub to IndexItem and then 883c177abb216fcef5b2d2369970394b0967f302 which removes it. There was no reason for that change and in my opinion no reason for it to now be in the git history. This kind of thing makes the git history harder to follow.

GuillaumeGomez

comment created time in 3 months

pull request commentrust-lang/rust

Fix going back in history to a search result page on firefox

I haven't been able to reproduce this issue locally. Is this a known Firefox bug? Are we even using window.onload?

GuillaumeGomez

comment created time in 3 months

pull request commentrust-lang/rust

Doc alias improvements

I squashed a few commits but kept the big changes into their own commits if this is ok with you.

There are still commits that makes changes that subsequent commits just revert. Feel free to r=me if you think it's too much work to clean up the commits or you don't want to squash into one commit. It's the end result that matters most after all.

GuillaumeGomez

comment created time in 3 months

pull request commentrust-lang/rust

Tiny Vecs are dumb.

Fun fact: until just a few days ago, I thought the "doubling" strategy was used for repeated push case.

I thought the same. It turns out that used to be the case until #50739. We will definitely need a regression test for this.

nnethercote

comment created time in 3 months

pull request commentrust-lang/rust

Add checking for no_mangle to unsafe_code lint

#[export_name = "..."] is unsafe for the same reason as #[no_mangle] so it should also be detected by this lint.

Nemo157

comment created time in 3 months

Pull request review commentrust-lang/rust

Doc alias improvements

 fn build_index(krate: &clean::Crate, cache: &mut Cache) -> String {                 parent_idx: None,                 search_type: get_index_search_type(&item),             });+            for alias in item.attrs.get_doc_aliases() {+                aliases+                    .entry(alias.to_lowercase())+                    .or_insert(Vec::with_capacity(1))
                    .or_insert(Vec::new())
GuillaumeGomez

comment created time in 3 months

more